codinuum / cca Goto Github PK

Hey team.
I noticed that recent changed introduced a small regression specifically

int main() {
  P *p = new P();
  foreach (QString arg, options->args)
    p->play(arg);
}

Crashes the parser with

PARSING ERROR: File "cpp_tree.ml", line 248, characters 22-28: Assertion failed

Somehow the fact that p was declared and then used in the macro confuses the hash table in the visitor.

Hello,
some users are trying to make a Spack package for cca, and have some difficulties:
spack/spack#18733

It would be very helpful if you could make an opam package for cca. We would then have the possibility to use opam-bundle to create a .tar.gz file containing cca and all its dependencies, and its installation on a machine without OCaml would then be very easy. I know it requires a little bit of time to make an opam package, but it is very beneficial in the long term for sharing your code.

best,
Anthony

For example here:

int main() {
  int *ptr = nullptr;
  foo.bar([&ptr]() {
    ptr = new int;
  });
  return 1;
}

The assignment ptr = new int; fails. Maybe inside the context of a lambda (as argument) primitives types are not seen as types?

Hey Codinnuum team,

Your parser is amazing and this is the only issue in a while that we found.

With this file as input: https://git.yoctoproject.org/linux-yocto-contrib/plain/tools/testing/selftests/kvm/x86_64/pmu_event_filter_test.c

Cca does not produce any output (or terminate) for minutes. There is no memory consumption so I assume it's some recursion but we haven't found the problematic part of the code.

Hey team, your project is amazing. I noticed that the following c++ code:

static_assert(std::is_same_v<A, const int&(int)>);

does not parse, but this one does:

static_assert(std::is_same_v<A, int&(int)>);

The following fails to parse:

1. typedef with struct declaration

typedef struct A {} *LP_A;

2. template disambiguator for dependent names

class c {
    struct t {
        template<template<typename V0> class V> struct s {};
        template<typename V> static void f( s<V::template r>* = 0 );
    };
};

This might be an intentional choice so feel free to close the issue.
I have noticed that the following codes produce the same AST:

for (;cond();) {}

and

for (;;iter()) {}

In the sense that, from the AST itself, it is not possible to determine which expression is the loop-condition and which is the iteration-expression.

I understand that this might be non-trivial to fix. I noticed that empty init_statement in represented as ExpressionStatement. Maybe if there was a similar place-holder for an empty(non-present) expression? Or if ForStatement had a fixed number of children that may be empty?

Hey team. You are doing an amazing work. ❤️
I'm not sure if this is an actual issue or a known "feature", but in the following code:

#ifdef __cplusplus
extern "C" {
#endif
struct foo;
#ifdef __cplusplus
} /* End extern "C".  */
#endif

The AST tree looks a bit weird. It looks like the linkage-specification has higher priority than the pre-processor conditionals. I understand that it's impossible to parse all non-pre-processed code. Just wanted to ask if this is known.

The types from complex.h seem to be parsed in other contexts, e.g.

bar<double _Complex>();
float _Imaginary ** c;

But the same types are refused by the parser when given to sizeof operator, e.g.

std::size_t double_size = sizeof(double _Complex);

hi @codinuum , thank you for this super library
I tried running it on a popular C++ library (https://github.com/ceph/ceph) and ran into a few parse errors.
Here's one file affected (src/common/FixedCDC.cc):

// -*- mode:C++; tab-width:8; c-basic-offset:2; indent-tabs-mode:t -*-
// vim: ts=8 sw=2 smarttab

#pragma

#include "FixedCDC.h"

void FixedCDC::calc_chunks(
  const bufferlist& bl,
  std::vector<std::pair<uint64_t, uint64_t>> *chunks) const
{
  size_t len = bl.length();
  if (!len) {
    return;
  }
  for (size_t pos = 0; pos < len; pos += chunk_size) {
    chunks->push_back(std::pair<uint64_t,uint64_t>(pos, std::min(chunk_size,
								 len - pos)));
  }
}

The recursive processing of declaration like X****.. seems to use large amount of memory (>10GB).

For example this clang test: https://github.com/llvm/llvm-project/blob/main/clang/test/CodeGenCXX/mangle-extreme.cpp

So for example:

struct final final {};

is a legal definition.

https://en.cppreference.com/w/cpp/language/final

Hey cca team, thank you for the amazing work.
We noticed that some syntax causes issues with parsing, specifically:
1)

struct left {} constexpr right{};

It seems that the parser does not expect constexpr in this declaration context.
2)

auto [a,b]{c()};

Directly calling the constructor of the structured binding instead of the more common assignment operator, e.g. auto [a,b] = c();, causes parser error.

This is probably more of a feature-request:

int main() {
  if (A* a = get_A()) return 1;
  return 0;
}

Will translate the condition as assignment where lhs is a multiplicative-expression.

int main() {
  if (A a = get_A()) return 1;
  return 0;
}

Will translate as macro A applied to a.

I understand it's ambiguous without knowing what is a type but a similar code outside of an if-statement works as expected, e.g.

int main() {
  A* a = get_A();
  return 0;
}

Is it because the parser by default expects the condition to be an expression?

Hello and thanks again for your amazing project.

I've noticed a strange AST for the following code:

struct Foo {
  Foo(int b) {}
};
void bar() {
  Foo f(1);
}

The declaration of f is split into StatementMacro:Foo and function-call f(1). But if I add return statement after the declaration:

struct Foo {
  Foo(int b) {}
};
void bar() {
  Foo f(1);
  return;
}

The AST looks as expected.