[clang] `LambdaExpr::hasExplicitParameters()` returns `true` for lambdas with a trailing return type

[WillemKauf]

(LLVM version 20.1.8)

For context, I am writing a clang-tidy pass for a codebase which deals with lambda coroutines, and need to disambiguate between a lambda with an empty parameter list like:

auto l = [](){};

and an implicit parameter list like:

auto l = []{};

hasExplicitParameters() correctly returns false, true in the above cases, but when adding a trailing return type (which is needed to properly define a lambda coroutine), hasExplicitParameters() no longer returns what you would expect, e.g.

auto l = []() -> int { return 0; };

auto l = [] -> int { return 0; };

Here, hasExplicitParameters() returns true, true.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: Willem Kaufmann (WillemKauf)

For context, I am writing a clang-tidy pass for a codebase which deals with lambda coroutines, and need to disambiguate between a lambda with an empty parameter list like:

auto l = [](){};

and an implicit parameter list like:

auto l = []{};

hasExplicitParameters() correctly returns false, true in the above cases, but when adding a trailing return type (which is needed to properly define a lambda coroutine), hasExplicitParameters() no longer returns what you would expect, e.g.

auto l = []() -> int { return 0; };

auto l = [] -> int { return 0; };

Here, hasExplicitParameters() returns true, true.

[zygoloid]

Looks like we get this wrong here: we assume if there's a function declarator chunk then there were explicit parameters, which used to be true when a trailing return type required a parameter list, but isn't any more. Presumably we could detect explicit parameters by looking for an LParenLoc on the function declarator chunk, or something along those lines.

[AaronBallman]

Marking this as a good first issue because I think @zygoloid is correct about how to approach this.

[llvmbot]

Hi!

This issue may be a good introductory issue for people new to working on LLVM. If you would like to work on this issue, your first steps are:

1. Check that no other contributor is working on this issue. If someone is assigned to the issue or claimed to be working on it, ping the person. After one week without a response, the assignee may be changed.
2. Leave a comment indicating that you are working on the issue, or just create a pull request after following the steps below. Mention this issue in the description of the pull request.
3. Fix the issue locally.
4. Run the test suite locally. Remember that the subdirectories under test/ create fine-grained testing targets, so you can e.g. use make check-clang-ast to only run Clang's AST tests.
5. Create a Git commit.
6. Run git clang-format HEAD~1 to format your changes.
7. Open a pull request to the upstream repository on GitHub. Detailed instructions can be found in GitHub's documentation. Mention this issue in the description of the pull request.

If you have any further questions about this issue, don't hesitate to ask via a comment in the thread below.

[llvmbot]

@llvm/issue-subscribers-good-first-issue

Author: Willem Kaufmann (WillemKauf)

(LLVM version `20.1.8`)

For context, I am writing a clang-tidy pass for a codebase which deals with lambda coroutines, and need to disambiguate between a lambda with an empty parameter list like:

auto l = [](){};

and an implicit parameter list like:

auto l = []{};

hasExplicitParameters() correctly returns false, true in the above cases, but when adding a trailing return type (which is needed to properly define a lambda coroutine), hasExplicitParameters() no longer returns what you would expect, e.g.

auto l = []() -> int { return 0; };

auto l = [] -> int { return 0; };

Here, hasExplicitParameters() returns true, true.

[WillemKauf]

I suppose I'll tackle this and try to get a fix up later today.