_Builder in source_gen uses code like this to check that the generated
file is expected in the library. While it is a questionable approach,
I don't feel that I have time to fix it, and remove the `uri` property
completely. So, we fix in in Analyzer with summary2.
`if (!library.parts.map((c) => c.uri).contains(part)) { ...fail... }`
R=brianwilkerson@google.com, paulberry@google.com
Change-Id: I983f29589cbb2613d5f896b87f6218c31a47afa9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/105601
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
It doesn't work to make TypeParameterElement.type choose
nullability/non-nullability based on the enclosing library, because
for type parameters of synthetic function types, there is no enclosing
library.
Change-Id: Ic74cc639534e3c03f3c46e7eacfb5655ca74019a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/102981
Auto-Submit: Paul Berry <paulberry@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
1. Read GenericFunctionType fully, but in two steps to avoid recursion.
We need to read it fully, because it might be a part of a const
initializer, so the client might request the initializer expression,
and there is no way to him to finish reading. Amnd in general, we
don't read expressions lazily.
2. For consistency we need to set identifiers for all GenericFunctionType
nodes that we want to store. So, DeclarationResolver should be updated
to move the identifier number even though we don't use the same
mechanism for building elements ininitializers, as we use for type
annotations outside expressions.
R=brianwilkerson@google.com
Change-Id: I58faa5408bff5250a8c775249438def7f742594b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/102840
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
1. Don't store tokens.
2. Start moving toward storing only semantic information.
3. Don't use DeclarationSplicer, DeclarationResolver.
4. GenericFunctionType(s) don't work, we need a way to associate AST
location to summary location. I think it is solvable.
Change-Id: If0bf9f20f8092068488322129853b788dd947eb0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/102127
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This is needed for two reasons:
1. Summary linking, because type inference needs to behave differently
for opted-in vs. opted-out libraries.
2. Summary resynthesis, because TypeParameterElement.type needs to
behave differently for opted-in vs. opted-out libraries.
Note that reason 1 won't apply to the summary2 mechanism, because it
has access to full ASTs when doing type inference. But it will still
need to record compilation unit NNBD status for reason 2.
This CL merely stores the correct data in the summary; it doesn't
address resynthesis, linking, or summary2.
Change-Id: I1aa2226e5865ef76747267de6198223997d6ad0d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101920
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
In the long term this class will take over much of the role played by
RestrictedAnalysisContext. For now it is simply a container for the
analysis options, declared variables, type provider, and type system.
In follow-up CLs I will plumb this object through various parts of the
analyzer, especially the LinterContext; this will enable the
canBeConst... methods to be moved into SynchronousSession, and that
will allow us to stop creating a LinterContext in
BestPracticesVerifier.
Change-Id: I7ac2d386c10d2e5339d9715848b185c163e1f858
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101860
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This is necessary in order for resynthesis tests to be unambiguous in
the presence of NNBD, because with the old syntax, it wasn't clear
whether a type like `() -> int?` meant `int? Function()` or `int
Function()?`. In a future CL, we'll make a similar change
FunctionType.toString().
Change-Id: Iedf6162de53c7fe57f858913d8e82faac17971c0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101242
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
I elected not to provide an `sdkVersion` argument to FeatureSet for
these tests, on the grounds that if any new features are added to the
SDK before NNBD, we want to make sure that those features are
compatible with the NNBD summary behavior.
Change-Id: I62e383e903b5756dcbb8cb498e71c4e739731d3d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/101070
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
And change clients of the scanner (within the SDK) to use it.
Long term, it would be better to store the FeatureSet object directly
in the Scanner and remove the existing flags `enableGtGt` and
`enableNonNullable`. However there are analyzer clients that
currently use these flags. So for now, we simply plumb in the
FeatureSet as a new way of setting AstBuilder flags. Once we've
updated clients to use FeatureSet, we'll publish a breaking version of
the analyzer that removes the old flag API.
Change-Id: I9e662f4ed45668d9acd4f56e42d7d8dae6180d48
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/99975
Reviewed-by: Dan Rubel <danrubel@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
And change clients of parser and AstBuilder (within the SDK) to use
it.
Long term, it would be better to store the FeatureSet object directly
in the AstBuilder and remove the existing flags `enableNonNullable`,
`enableSpreadCollections`, `enableControlFlowCollections`, and
`enableControlFlowCollections`. However there are analyzer clients
that currently use these flags. So for now, we simply plumb in the
FeatureSet as a new way of setting AstBuilder flags. Once we've
updated clients to use FeatureSet, we'll publish a breaking version of
the analyzer that removes the old flag API.
Change-Id: I6d37177c40b1a1216956e95f473252aa218d10b8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/100000
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Dan Rubel <danrubel@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Konstantin Shcheglov