[Dot Shorthands] Analyzer Implementation

[kallentu]

This meta issue tracks all the analyzer implementation work items. Referenced from: https://github.com/dart-lang/sdk/blob/main/pkg/analyzer/doc/process/new_language_feature.md

Estimated work

• Parser

  • Need changes to identify when we have a shorthand, add all selectors
  • Recovery/error when . followed by a keyword?, some random symbol
  • Expressions can’t start with .

• AST enhancements (AstBuilder)

  • New AST type to represent the enum shorthand
  • . operator
  • And then the rest of the expression
  • Based on Paul’s prototype we need to represent a non-existent target (which he does with a “MAGIC” SimpleIdentifier)

• Summary support

  • Summaries record constants so I might need to do work here? Check with Konstantin

• Resolution

  • ResolverVisitor (type-based resolution)
    • Paul’s prototype used a stack of type schemas (named _enumShorthands). “When the ResolverVisitor enters the enum shorthand context node, it pushes the context onto this stack; when it leaves it, it pops it back off”
    • Work needed, tests needed.
    • == work in the TypeAnalyzer as well.

• Constant evaluation

  • We allow consts for enum shorthands.
  • Use the new AST.
  • Tests

• Index and search

  • Not entirely sure?
  • We can refer to a class without naming it. Might need updating?

• Warnings (annotation-based, unused*, strict-mode-based, a few others)

  • ErrorVerifier (report other errors and warnings)
    • Error when we are missing the context type
    • Error with asymmetric == and != (These errors might just belong in the ResolverVisitor?)
    • From @FMorschel : Check Ambiguous Import to make sure it triggers correctly for this case too.

• NodeLintRegistry

  • If we make a new AST node representing enum shorthands, should add it to this.

[FMorschel]

Not sure if here is the place but we could add a lint to tell the user to use this feature where possible prefer_dot_shorthands or something, with a quick-fix (server) to remove the initial part.

Also, one question to have in mind here would be: what about prefixed imports that expose that element? Will this feature work with it?

Another error to look at would be Ambiguous Import to make sure it triggers correctly for this case too.

---

If these points should be somewhere else please say so and I can move them. If I missed anything please let me know!

[kallentu]

Not sure if here is the place but we could add a lint to tell the user to use this feature where possible prefer_dot_shorthands or something, with a quick-fix (server) to remove the initial part.

We are planning to add that, yes! I've added it onto the analysis server work issue (under quickfixes for now) #59836

Also, one question to have in mind here would be: what about prefixed imports that expose that element? Will this feature work with it?

Yep, prefixed imports with shorthands should work as well. There are some language tests covering this behaviour.

Another error to look at would be Ambiguous Import to make sure it triggers correctly for this case too.

Good point. Added this, thank you!