#2641. Add tests for multiple declarations named _

[sgrekhov]

No description provided.

[eernstg]

Looks good! I think one location needs to change (it's an unwanted compile-time error), and it would be good to have a bit more on constructors.

[sgrekhov]

Fixed (and some other typos) except constructor tear-offs. Please clarify what is expected?

[eernstg]

Looks good! With some tear-off related test cases, it should be fine!

[sgrekhov]

Added binding_A01_t11.dart. PTAL

[eernstg]

Looks good! Just one thing remaining: The testing of constructor tear-offs will not reveal the specific faults that I mentioned, as far as I can see. I wrote a rather long comment about this, PTAL.

[sgrekhov]

Thank you for the details. I updated the test, please take a look. I'm not sure that we can check that arguments were received correctly in case of wildcards. If I misunderstood you, please correct me

[eernstg]

Ah, you're right: The original constructor has parameters whose name is _, so the corresponding actual arguments must be ignored.

We have a couple of tricky cases where that's not true:

class A {
  final int _;
  A(this._);
}

The language team wants to enable this (I'm at most lukewarm on that), and it should initialize the instance variable whose name is _ (that's not a wildcard). At the same time, this initializing formal does not introduce a local variable into the 'formal parameter initializer scope', which means that A(this._): anotherVariable = _; would be an error.

However, let's postpone tests about this._ and super._ until the language team has concluded something.

(I don't remember, but if we already have some tests about those things then we should just make sure they don't create any noise, e.g., by causing tools to be changed such that they pass a test that may need to be changed.)

Anyway, this is all we can test at this time, so I'll land the PR.

[eernstg]

LGTM

[eernstg]

LGTM (fixed a typo).

[eernstg]

Issue about super._: dart-lang/language#3792. There is no separate issue about this._ as far as I know.

[sgrekhov]

(I don't remember, but if we already have some tests about those things then we should just make sure they don't create any noise, e.g., by causing tools to be changed such that they pass a test that may need to be changed.)

No, we don't have such tests yet. They will be added later as test for Initializing formals part of the spec

[eernstg]

Sounds good, thanks! The language team just decided that super._ and this._ are allowed (super._ when it occurs as a declaration of a positional parameter, not a named one). super._ gives rise to a forwarding semantics in that the actual argument passed to that parameter is also passed to the superconstructor (even though we couldn't write the code to do that because there is no name for that parameter in scope). this._ will initialize an instance variable named _, and it is not possible to reference that parameter by means of _ in the initializer list (but it could be a top-level or static thing, as usual).