This should handle all cases of constructor reference w/ explicit type
args; there aren't too many cases:
* named and unnamed constructors
* referencing class and referencing type alias
* prefixed class names and not-prefixed
* null-aware access (weird)
* bound on type parameter of class, and on type parameter of alias
error cases:
* cascade
* wrong number of type arguments
Bug: https://github.com/dart-lang/sdk/issues/46020
Change-Id: If257eb561a9ad854709b6e9a7d81faa9d084d6ee
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209622
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Of the two classes that inherit from ScopedVisitor (ResolverVisitor
and ScopeResolverVisitor), only ResolverVisitor needs to know about
the currently enclosing class, extension, and function. So we move
this tracking logic to the ResolverVisitor itself. This will help
pave the way for a cleaner separation between the ResolverVisitor and
ScopeResolverVisitor.
(The ScopeResolverVisitor *does* need to know the currently enclosing
closure, so that it can detect improper break/continue statements and
so that it can detect when a local variable is mutated in a closure,
but the tracking logic needed for this is much simpler than what the
ResolverVisitor needs for the "enclosing function". So a new
_enclosingClosure member has been added to ScopeResolverVisitor to
track this.)
Change-Id: I768c15ff4ffcabf564388f5471a6e8f88e677148
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209665
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
This is the beginning of an arc of work to move the responsibility of
all the analyzer's scope-based resolution into a single class.
VariableResolverVisitor will become that class, so accordingly it's
being renamed to ScopeResolverVisitor.
In the long term, this shift of responsibility will bring the analyzer
and the CFE into better alignment by removing scope resolution logic
from the type analysis phase (the CFE performs all scope resolution
during parsing, and then has a single visit pass to do type analysis).
This should allow analyzer and CFE logic to be more readily shared.
Also, it should improve the performance of the analyzer by allowing
Scope objects to be built up in just a single visitor pass rather than
in multiple visitor passes.
Change-Id: I037346d28de6485cac783e2bc65e0de9d3a2ada6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208661
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This CL refactors the scope lookup logic for simple identifiers so
that it happens in three phases:
- The actual lookup, handled by Scope.lookup
- Choosing which element is being referred to, handled by the
LexicalLookup class
- If lexical lookup failed, falling back on implicit `this` lookup,
handled by the ThisLookup class
In a future CL, this will allow us to consolidate the first phase,
along with all other scope-related operations, into a single visitor
so that the ResolverVisitor no longer needs to maintain scopes. This
should simplify the analyzer's scoping logic and help prepare for
sharing more code with the CFE (since it will make the analyzer's
visitors more closely parallel the analysis phases of the CFE).
Change-Id: I0c8a2aa60bfc5a935b6060adf64e5a4504bc268f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209664
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Currently, if a type parameter of a class, mixin, or extension
declaration has an annotation, that annotation is resolved in the type
parameter scope of the class, mixin, or extension declaration (meaning
that static methods are not in scope), however if scope lookup fails,
then static methods are accessible via implicit `this`.
AFAICT, this odd behavior is not spec compliant, so I've filed
https://github.com/dart-lang/language/issues/1790 to discuss the
possibilty of changing it. However, for now I want to unit test the
behavior in order to ensure that if we make any changes to the
analyzer that affect it, the change won't go unnoticed.
Bug: https://github.com/dart-lang/language/issues/1790
Change-Id: I02df7e6e8939ecc6222085f28a6d6b7d072179c1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209662
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
For some time, the visitors we use for resolution have been handling
documentation comments for most types of declarations by visiting them
*after* visiting parameters; this ensures that the parameters are in
scope at the time of visiting the documentation comment, so that the
documentation comment can refer to them.
However, a few types of declarations were done in a kludgy way:
constructor declarations, function declarations, function type
aliases, generic type aliases, and method declarations. In some cases
we would visit the documentation comment twice, once before setting up
the scope properly (in which case the visit method would just return
early), and then again at the right time using
ResolverVisitor.safelyVisitComment (which bypassed the early return).
On other cases the visitComment method had duplicate logic for setting
up the proper scopes.
With this change, we now consistently use the approach of visiting the
documentation comment after the scopes are properly set up for it.
Change-Id: Idd27946a947040d4bad37568915bf5915bff843f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/209240
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This saves the ExtensionMemberResolver from having to access the
current scope in order to find out what extensions are available.
This will help prepare for a follow-up CL in which I separate the
"scope lookup" and "type analysis" phases of resolution.
As a side benefit, the analysis server no longer needs to go through
`package:analyzer/src` in order to include extensions in completion
results.
Change-Id: I6098eae219b0f7ef52b7c68f1d64c149d9e66823
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208922
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
A constructor without a name is an "unnamed" constructor. A class which
has no constructors explicitly specified implicitly has one "default
constructor". See from the spec:
> Iff no constructor is specified for a class _C_, it implicitly has a
> default constructor `C(): super() {}`, unless _C_ is the built-in
> class `Object`.
This is the singular reference in the spec to this "default
constructor." There is text which refers to the implicit
superinitializer which refers to the superclass's unnamed constructor
which must have zero arguments:
> If no superinitializer is provided, an implicit superinitializer of
> the form `super()` is added at the end of _k_'s initializer list,
> unless the enclosing class is class `Object`.
Change-Id: I3202c3923d2c561d40c2251c1b13ea4fde8bda48
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208865
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This adds support for both declaring an unnamed constructor with the
explicit name, "new", and support for invoking an unnamed constructor
as a named constructor named "new".
The parser will report EXPERIMENT_NOT_ENABLED if the experiment is not
enabled, as the parser takes care around the keyword, "new".
Tearoff support will be separate.
Bug: https://github.com/dart-lang/sdk/issues/46020
Change-Id: Iaf3af333dd22337b560aa7f4e5811a4cb38b2a7f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208760
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
This logic was previously in LibraryScope and ScopeExtension. It
really isn't related to scopes, though, since all it does is to look
through the library's imports and parts. (The only use it made of
scopes was to locate the library element).
Separating this code from scopes will facilitate some other changes
I'm working on to streamline the use of scopes in the analyzer.
Change-Id: Ic45e3382628a433a96cc7ecf751b4df5d681b42a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208522
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
We had logic for tracking this information in both
VariableResolverVisitor and ResolverVisitor, both of which share the
common base class ScopedVisitor. It makes more sense to put this
logic in one place in ScopedVisitor.
Change-Id: I1cb0350039587cb67b26eda5830a8cad2d922027
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208561
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This will be used in internal builds to ensure that an exception
occuring during linting fails the build; this should help us be more
confident in the robustness of the linter code.
Change-Id: I4eaa47044b32b45433a67cc919ad047663dc771c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208141
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In the two LibraryAnalyzer classes, the list of visitors is always
empty, so there are never any "visitor based lints" to run. (I
suspect that all the visitor based lints were long ago converted to
use the node registry, leaving this code dead).
Removing the last remnants of the visitor based lint logic allows us
to remove the ExceptionHandlingDelegatingAstVisitor class, which in
turn allows us to move its logException method into a simpler class.
In a follow-up CL, I will expand on this class to allow its behavior
to be customized.
Change-Id: I1261a94572ea65eb220a58fb45f6d887e6497fe9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/208140
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Sam Rawlins