After recursive types are gone, finalization of types can be
simplified: types can be finalized with a simple recursive traversal
and they no longer need to track "being finalized" state.
Also, finalization doesn't need to write back finalized types
because type finalization without canonicalization is always performed
in place and doesn't result in a new type (or type arguments vector).
TEST=ci
Change-Id: Ifc0a4e12aa410eb2be18c4a475c2f486cfa9ebf2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/299300
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Reviewed-by: Ryan Macnak <rmacnak@google.com>
For class type parameters 'parameterized_class_id' duplicates
a recently added 'owner' and can be removed.
'owner' is changed to hold class reference as a class id (Smi).
TEST=ci
Change-Id: I93fc11e6bcfcc00058a5281b497f59c5c5847ea6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/299160
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
TypeRef type wraps around another type and it was used to represent
a graph of recursive types. After [0], the only use of TypeRef is
for TypeParameter.bound which may indirectly reference the same
TypeParameter.
This change replaces TypeParameter.bound with TypeParameter.owner and
removes TypeRef entirely. Various parts of the VM no longer need to
handle and support TypeRefs.
TypeParameter.owner can reference a FunctionType, Class,
or, as an optimization, it can be set to null in order to share
class type parameters among different classes.
With the exception of the 'TypeParameter.owner' back pointer,
VM types are now not recursive and can be visited without
additional tracking.
Caveats:
* Generic FunctionType cannot be cloned in a shallow way:
when copying a FunctionType, type parameters should be cloned too
and their owners should be updated. For that reason,
a mapping between 'from' and 'to' function types
(FunctionTypeMapping) is maintained during type transformations
such as InstantiateFrom.
FunctionType::Clone is used instead of Object::Clone where
appropriate.
* When testing types for subtyping and equivalence, mapping
between function types is passed to make sure
type parameters belong to the equivalent function types.
* IL serializer needs to serialize function types as a whole before
serializing any types potentially pointing into the middle of a
function type (such as return type 'List<Y0>' pointing into
the middle of a function type 'List<Y0> Function<Y0>()').
[0] https://dart-review.googlesource.com/c/sdk/+/296300
TEST=ci
Change-Id: I67c2fd0117c6183a45e183919a7847fd1af70b3e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/294165
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
We use the MSVC from Depot Tools to build C files.
When using clang from DEPS, we need to pass the right INCLUDE / LIB
environment variables. So we might as well use the MSVC instead.
Moves the `nativeCompilerEnvironmentVariables` to the
`TestConfiguration` so that it's cached.
Bug: https://github.com/dart-lang/sdk/issues/50565
Change-Id: I3576cd0ed07081afb9ae5ba737b8bfe1b21941e5
Cq-Include-Trybots: luci.dart.try:pkg-win-release-try,pkg-mac-release-try,pkg-mac-release-arm64-try,pkg-linux-release-try,pkg-linux-debug-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/298580
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
This change fixes parsing of case clauses such as:
case foo when !flag:
Constructions like this require some lookahead in order to parse
correctly, because the token `when` is valid both as an identifier and
as a part of the grammar for a case clause. Therefore, at the time
`foo` is encountered, the parser must decide whether it is looking at
a variable pattern (`foo when`, where `when` is the name of the
variable) or an identifier pattern (`foo`, where `when` begins the
case's guard clause). Previous to this fix, the algorithm for
disambiguating these two choices was as follows:
- If the token sequence starting at `foo` looked like a type, and the
token that follows was an identifier, the parser assumed it was
looking at a variable pattern with a type; otherwise it assumed it
was looking at an identifier pattern.
- EXCEPT that if the token that followed the supposed type was `when`
or `as` (both of which are valid identifiers), then it probed
further:
- If the token that followed `when` or `as` was a token that could
legitimately follow a pattern, then it assumed that it was looking
at a variable pattern with a type. (The tokens that could
legitimately follow a pattern are `,`, `:`, `||`, `&&`, `)`, `}`,
`]`, `as`, `when`, `?`, `!`).
- Otherwise it assumed that it was looking at an identifier pattern.
This didn't fully disambiguate, because the third bullet didn't
account for the fact that the tokens `as`, `when`, and `!` could
_either_ legitimately follow a pattern _or_ legitimately begin an
expression (or, in the case of `when`, a type), therefore constructs
like the following were incorrectly parsed:
- `case foo when as:` (where `as` is a local boolean variable)
- `case foo when when:` (where `when` is a local boolean variable)
- `case foo when !flag:` (where `flag` is a local boolean variable)
- `case foo as when:` (where `when` is the name of a type)
The solution is to simplify the disambiguation logic so that if if the
token that follows the supposed type is `when` or `as`, then the
parser assumes that it's looking at an identifier pattern, _not_ a
typed variable pattern.
The consequence of this is that the above four constructions are
parsed correctly; however it is no longer possible for a typed
variable pattern to name a variable `when` or `as`.
For consistency we would like to prohibit _any_ variable pattern from
naming a variable `when` or `as`, however to keep this change as small
as possible (and reduce the risk involved in a possible cherry-pick)
that will be postponed until a later CL.
Fixes#52199.
Bug: https://github.com/dart-lang/sdk/issues/52199
Change-Id: Ibab9b92f01e3e4020d7d64f1ff000a9b964a4564
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/299400
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
If enum values have used defined fields that use fromEnvironment constants
the enum values themselves are seen as unevaluated constants when
compiling with dart2js. This means that the enum value are not recognized
correctly in exhaustiveness checking.
This CL changes the enum value representation of the CFE to use the
enum class and the name of the enum element, derived either from the
instance constant or the unevaluated constant expression.
Change-Id: I7d5791a41349dacd20b588f5dbfca37d8755ef79
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/299100
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
This allows void typed switch expressions by allowed void typed
expressions in all subexpressions inferred through the shared type
analysis.
This might lead to allowing void in intended places but the current
approach employed by the CFE doesn't really scale so we need to revisit
it anyway.
In response to https://github.com/dart-lang/sdk/issues/52191
Change-Id: Iee53670d3c316764cfc1309dc76cf37bb3b03629
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/299020
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
When compiling "compile.dart" the type given to computeNonNull
is already non-nullable in ~42% of the cases, meaning it spends
time not doing anything.
Change-Id: I94598efceb3b46f0ac81ec36814c216d01a9e38b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/298823
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Type inference is not tracking the type of 'local' correctly through the switch statement into the inner return. The same code without the for loop does work correctly though.
Change-Id: I0b1b4741e4ff17c22dec3383defb412f5fff0836
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/298980
Reviewed-by: Stephen Adams <sra@google.com>
Reviewed-by: Mayank Patke <fishythefish@google.com>
Commit-Queue: Nate Biggs <natebiggs@google.com>
This adds a BodyBuilderContext to separate the BodyBuilder from its
[member], [declarationBuilder] and [sourceClassBuilder] fields. The
latter two are fully removes and trivial uses of [member] have been
removed.
This is a step towards a more clean implementation of inline class
members. The plan is to have the members create their own
BodyBuilderContext to use in the BodyBuilder which should the be
agnostic about the builders of its context.
Change-Id: Ic3b29693dd26aa8c57a9ac175b4a07ce4b0a15d7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/298860
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
InstanceAccessTarget calls "base.getGetterTypeForMemberTarget" a lot;
this CL caches the result which is almost always a new FunctionType,
thus creating fewer FunctionTypes.
When compiling compile.dart ~29% fewer:
Before this CL, compiling compile.dart created a little over 217k
FunctionTypes (down in a previous CL from almost 263k); with this CL
"only" ~153.5k FunctionTypes are created.
Change-Id: Ib110ed5e0d152a3b86044f20dc50f0924a083f46
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/298601
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Alexander Markov