[c++17] lambda capture by reference does not work

[i-garrison]

Just realized the test below is part of https://bugs.eclipse.org/bugs/show_bug.cgi?id=561128 discussion.

The following code is at least c++17 because it evaluates constexpr lambda in constexpr context.
Computed result value is integer 2.

Eclipse CDT supports constexpr lambda and is able to perform evaluation thereof.

Unfortunately CDT evaluations of both local lambdas effectively capture acc by value so calling any of them do not affect the acc in enclosing function scope. This causes CDT to evaluate lambdainc() as integer 0 which yields wrong non-type argument to Evaluate<> .

template<int V> struct Evaluate {};
template<> struct Evaluate<2> { static constexpr int value = 2; };

constexpr auto lambdainc()
{
	int acc = 0;

	auto incDefaultCapture = [&]() constexpr { return ++acc; };
	auto incCaptureByReference = [&acc]() constexpr { return ++acc; };
	incDefaultCapture();
	incCaptureByReference();

	return acc;
}

// Error mark on 'result' initializer below says: Symbol 'value' could not be resolved
// this is because lamdainc() is currently evaluated to 0 and Evaluate<0> does not contain 'value'
static constexpr auto result = Evaluate<lambdainc()>::value;

Expected behavior
CDT evaluation of both lamdas should capture acc from enclosing function scope by reference.
lambdainc() should evaluate as integer 2

[ghentschke]

@i-garrison Do you use cmake based or managed projects in CDT?
I testet the snippet in the new LSP based C/C++ editor and it works as expected, when setting the C++ standard to 17 in the CMakeLists.txt.

[i-garrison]

Hi @ghentschke I'm still using the original CDT parser that's where I see the issue. Guess LSP-based one has no problems.

I'm using managed build projects, there I configure them to use compile_commands.json exported from build system (by hand, either via cmake or via meson depending on the project) so that all include paths and macros match respective project build environments.

[ghentschke]

I'm using managed build projects, there I configure them to use compile_commands.json exported from build system

Then I would recommend to give the new editor a try ;-)
If the compile_commands.json is not in the source tree, all it needs is a .clangd file in the source tree containing the path to the compile_commands.json, :
i.e.:

CompileFlags:
  CompilationDatabase: build/debug

[i-garrison]

Yeah would be nice to see LSP editor as part of future CDT release, but until then this bug is about existing CDT parser.