[macros] support for non_constant_identifier_names (variables and fields)

[pq]

No description provided.

[pq]

I'm assuming we should try and avoid linting where the augmentation author can't do anything. For example, I expect that Mm should not be linted in the augmented A.

class A {
  void Mm() { }
}

augment class A {
  augment void Mm() { }
}

But I have some open questions.

My sense is we should NOT lint the Ss param in the augmented m since Ss cannot be renamed.

class A {
  void m({String? Ss}) { }
}

augment class A {
  augment void m({String? Ss}) { }
}

But what about an unnamed parameter that matches the augmented parameter name?

class A {
  void m(String? Ss) { }
}

augment class A {
  augment void m(String? Ss) { }
}

Or, more oddly,

class A {
  void m(String? s) { }
}

augment class A {
  augment void m(String? Ss) { }
}

Are these cases worth handling?

Overrides.

It's worth noting that we don't do anything smart for overrides which are similar and produce lints whether the code author can do anything about them or not.

I'm pretty sure that's not the best behavior but I guess it comes up rarely enough in practice.

Thoughts on what we should do here?

/cc @bwilkerson @munificent

[bwilkerson]

I'm assuming we should try and avoid linting where the augmentation author can't do anything.

I agree. I think that's a concrete application of an even more general principle: we shouldn't lint where the author can't do anything to fix it.

For example, I expect that Mm should not be linted in the augmented A.

I agree. They need to change the declaration being augmented first (and rename should rename any augmentations in the process).

But what about an unnamed parameter that matches the augmented parameter name?

As far as I can tell from the proposal it's fine if the names of positional parameter differ, so I'm guessing that we should lint that.

It's worth noting that we don't do anything smart for overrides ...

I think we should stop linting the names of overriding methods and the names of named parameters in overriding methods.

[pq]

With https://dart-review.googlesource.com/c/sdk/+/352978, all he cases except for variables and fields (which the parser doesn't support yet) should be covered.

[pq]

Fixed w/ 1c461dc