Bugzilla

(In reply to Steven Michaud [:smichaud] (Retired) from comment #85)
> As I mentioned above in comment #80, the "lambda glue" replacement for the call to `NS_NewRunnableFunction()` actually takes just one parameter -- an array of captured object pointers (smart or dumb). So the `RunnableFunctionImpl()` rigamarole seems intended to allow only altered calls to `NS_NewRunnableFunction()` to be compilable. I suspect that `NS_NewRunnableFunction("MyString", lambda)` wasn't altered (when it was still compilable), and this is what broke the compiler's "lambda glue". Edit: I've confirmed this by looking at my "broken" testcase in [Hopper Disassembler](https://www.hopperapp.com/). The assembly code is *much* more readable there than at https://godbolt.org/.
> 
> > I suspect that NS_NewRunnableFunction("MyString", lambda) wasn't altered
> 
> It *was* altered, but so that it took *no* parameters. So it still didn't match the signature of a "correctly" altered `NS_NewRunnableFunction()`.

This is wrong :-( The compiler errors happen at the "Parsing" stage -- before the "Semantic Analysis" stage. At this point the "lamda glue" hasn't yet been created, and `NS_NewRunnableFunction()` still has two parameters. The "`RunnableFunctionImpl()` rigamarole" is just a way to make the compiler fussier about the second parameter, `aFunction()`. Without it the compiler accepts both `[T = (lambda at lambda-testcase.cpp:nnn:nn) &]` (the "broken" case) and `[T = (lambda at lambda-testcase.cpp:nnn:nn) &&]` (the non-"broken" case). With it the compiler only accepts `[T = (lambda at lambda-testcase.cpp:nnn:nn) &&]`.

And so the compiler errors *aren't* misleading.

(In reply to Steven Michaud [:smichaud] (Retired) from comment #85)
> As I mentioned above in comment #80, the "lambda glue" replacement for the call to `NS_NewRunnableFunction()` actually takes just one parameter -- an array of captured object pointers (smart or dumb). So the `RunnableFunctionImpl()` rigamarole seems intended to allow only altered calls to `NS_NewRunnableFunction()` to be compilable. I suspect that `NS_NewRunnableFunction("MyString", lambda)` wasn't altered (when it was still compilable), and this is what broke the compiler's "lambda glue". Edit: I've confirmed this by looking at my "broken" testcase in [Hopper Disassembler](https://www.hopperapp.com/). The assembly code is *much* more readable there than at https://godbolt.org/.
> 
> > I suspect that NS_NewRunnableFunction("MyString", lambda) wasn't altered
> 
> It *was* altered, but so that it took *no* parameters. So it still didn't match the signature of a "correctly" altered `NS_NewRunnableFunction()`.

This is wrong :-( The compiler errors happen at the "Parsing" stage -- before the "Semantic Analysis" stage. At this point the "lambda glue" hasn't yet been created, and `NS_NewRunnableFunction()` still has two parameters. The "`RunnableFunctionImpl()` rigamarole" is just a way to make the compiler fussier about the second parameter, `aFunction()`. Without it the compiler accepts both `[T = (lambda at lambda-testcase.cpp:nnn:nn) &]` (the "broken" case) and `[T = (lambda at lambda-testcase.cpp:nnn:nn) &&]` (the non-"broken" case). With it the compiler only accepts `[T = (lambda at lambda-testcase.cpp:nnn:nn) &&]`.

And so the compiler errors *aren't* misleading.

(In reply to Steven Michaud [:smichaud] (Retired) from comment #85)
> As I mentioned above in comment #80, the "lambda glue" replacement for the call to `NS_NewRunnableFunction()` actually takes just one parameter -- an array of captured object pointers (smart or dumb). So the `RunnableFunctionImpl()` rigamarole seems intended to allow only altered calls to `NS_NewRunnableFunction()` to be compilable. I suspect that `NS_NewRunnableFunction("MyString", lambda)` wasn't altered (when it was still compilable), and this is what broke the compiler's "lambda glue". Edit: I've confirmed this by looking at my "broken" testcase in [Hopper Disassembler](https://www.hopperapp.com/). The assembly code is *much* more readable there than at https://godbolt.org/.
> 
> > I suspect that NS_NewRunnableFunction("MyString", lambda) wasn't altered
> 
> It *was* altered, but so that it took *no* parameters. So it still didn't match the signature of a "correctly" altered `NS_NewRunnableFunction()`.

This is wrong :-( The compiler errors happen at the "Parsing" stage -- before the "Semantic Analysis" stage. At this point the "lambda glue" hasn't yet been created, and `NS_NewRunnableFunction()` still has two parameters. The "`RunnableFunctionImpl()` rigamarole" is just a way to make the compiler fussier about the second parameter, `aFunction`. Without it the compiler accepts both `[T = (lambda at lambda-testcase.cpp:nnn:nn) &]` (the "broken" case) and `[T = (lambda at lambda-testcase.cpp:nnn:nn) &&]` (the non-"broken" case). With it the compiler only accepts `[T = (lambda at lambda-testcase.cpp:nnn:nn) &&]`.

And so the compiler errors *aren't* misleading.