Bug: https://github.com/dart-lang/sdk/issues/49351
Adds checks for the following cases:
- Type arguments to createStaticInteropMock are correct
- No missing members in implementing class
- Inherited and non-overridden @staticInterop members are implemented
- Dart class can implement through inheritance and mixins
- Implemented members are correct subtypes of @staticInterop members
- Potential extension member conflicts that are attempted to be
resolved through subtyping rules
Change-Id: Iacbe5846040ba7fab41459aa19be77351cf1efca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255761
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Reviewed-by: Riley Porter <rileyporter@google.com>
Make the following changes, based on
https://github.com/dart-lang/language/commit/8a9b9a8a74a49e13c625e5208bab201d8a4f0e76:
- Replace `ConstOrLiteralPattern` nomenclature with `ConstantPattern`
(the spec no longer speaks of "literal patterns").
- It is an error if a guard's type is not assignable to `bool`.
- Variable patterns can now be `final`.
- We now have a separate error condition to cover the case where a
variable, list, map, record, or extractor pattern appears in an
irrefutable context and the matched type is not assignable to the
required type of the pattern. (Previously such patterns were simply
called "refutable", leading to a less clear error).
Additionally, we now consistenly use the term "guard" to refer to the
expression after a `when`, consistent with the spec text.
There are a few new TODOs, which I plan to address in follow-up CLs.
Change-Id: Ia0abab9492583f2aa8b59a9b381b90ba11b3e0fc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/259246
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This introduces a MemberName abstraction that supports the late
computation of member names, taking privacy and synthesized names
of unnamed extensions into account. With this feature, the unnamed
extension are now more directly handled as having no (known) name
which avoids the clash between the eagerly synthesized named of
unnamed extensions in different parts.
Closes#48765
TEST=existing
Change-Id: I62c00ace017141ecbc61eeecb275d0211f341c82
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/258800
Reviewed-by: Jens Johansen <jensj@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
This change refactors the logic for detecting overlapping and missing
variable patterns so that it can be invoked prior to the rest of type
analysis, rather than during it. In addition separating concerns
nicely (since no types are involved in these checks), I believe this
will facilitate integration with the analyzer and front end, by
allowing them to detect these errors and find the unique set of
variables defined by a pattern, at the time they are resolving
identifiers to their corresponding declarations.
Change-Id: I40879fca46d39e78a60813db007983e57a3aec31
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/259021
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
I've begun prototyping what it might look like to integrate the
current shared type analysis functionality with the analyzer and CFE,
and I've discovered some API improvements that are needed:
- The shared logic now handles the possibility that switch cases that
share a body have been merged prior to type analysis (because the
CFE merges them during parsing), in addition to the pre-existing
functionality which assumed that switch case merging had to be done
in the shared logic.
- The shared logic now returns several pieces of information as the
result of a call to `analyzeSwitchStatement`: whether the switch
statement had a `default` clause, whether it was exhaustive, whether
the last case body terminates, and the type of the scrutinee. These
are all needed by the CFE.
- The shared logic now allows `TypeAnalyzer.errors` to be `null`,
indicating that no errors should be reported. This reflects how
errors are suppressed during top level inference in the CFE.
- If a switch case lacks a `when` clause, this is reported by calling
`handleNoWhen` rather than passing a boolean to `handleCaseHead`.
- The shared logic now reports the appropriate error when a case
constant doesn't properly match the scrutinee's static type.
- Information about case labels is now delivered to flow analysis via
`switchStatement_endAlternatives` rather than
`switchStatement_beginCase`. This made it possible to rewrite the
shared `analyzeSwitchStatement` method in a way that requires less
bookkeeping, because it no longer has to peek ahead to look for
labels associated with a given case body.
- `TypeAnalyzer.analyzeExpression` is now responsible for
understanding that "no context" and a context of `dynamic` should
both be coalesced to `?`. The analyzer does this (although it's not
100% why), and it's definitely "business logic" that eventually
belongs in the shared type analyzer.
- `TypeAnalyzer.analyzeSwitchExpression` and
`TypeAnalyzer.analyzeSwitchStatement` no longer receive a list of
ExpressionCaseInfo / StatementCaseInfo objects describing the cases;
instead they query for them using a callback. This reduces the
lifetime of the ExpressionCaseInfo / StatementCaseInfo objects. In
the future, when we have record support, we could replace these
objects with records, which would then be passed on the stack,
avoiding any allocations.
- A new hook, `handleSwitchScrutinee`, is called right after visiting
the "scrutinee" expression of a switch expression or switch
statement. This hook is needed by the analyzer to compute
exhaustiveness. In a future CL, I hope to move exhaustiveness
analysis into the shared code as well, which should make this hook
unnecessary.
- `TypeAnalyzer.analyzeSwitchStatement` now reports an error if a
switch case completes normally and pattern support is not enabled.
- The test class `_MiniAstTypeAnalyzer` no longer overrides
`analyzeExpression` to provide a default context type; instead,
every call to `analyzeExpression` that didn't previously provide a
context now provides a context of `?`. Note that not all of these
are correct, but they are close enough for the unit tests we have
today. I plan to fix them in future CLs as I replace this logic
with shared logic.
- The hook `handleVariablePattern` is now always provided with a
static type. Previously, it was only provided with a static type if
this was the first time the variable was bound in the pattern.
Change-Id: I70e3c5468312a9329fcf4ad2e13749a32d2418e7
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/257487
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Rename `_CompactLinkedHashSet` to `_InternalLinkedHashSet` and
`_CompactImmutableLinkedHashSet` to `_InternalImmutableLinkedHashSet`
to make the names consistent with the corresponding `Map` class names
and to distinguish them from the non-VM-specific hash maps and sets,
which are generally named starting with `_Compact`.
Tested: ci
Change-Id: Ic1ebc44ba8beba34ceab382a4edddc6624fe3fb3
Cq-Include-Trybots: luci.dart.try:vm-kernel-precomp-linux-debug-x64-try
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/258002
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Update the documentation for TypeAnalyzer and related classes so that
they explain the behavior of each method in terms of its effect on a
stack. (The test logic already contained an implementation of such a
stack; production clients may or may not need to keep a stack
depending on their requirements). This should make it more
straightforward to write clients of TypeAnalyzer.
Also, beef up the test logic in flow_analysis_mini_ast.dart and so that:
- In the event of a test error, a source location is shown, so that
it's easy to debug and/or update the test. This source location is
obtained by parsing `StackTrace.current`, an approach which I
wouldn't recommend for production code, but which is servicable for
these low-level tests.
- Items that are popped off the stack are checked to make sure they
have the expected kind.
The kind-checking caught a minor flaw in the previous test logic: it
was failing to distinguish expressions from expression statements.
This as been corrected, and as a result, a few test expectations in
type_inference_test.dart needed to be updated.
Change-Id: I0a2b257f6e970478c0c8e1b663dd5a367e7f24ec
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/257486
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
localMembersIterator uses filteredIterator under the hood, meaning that
it does a `is T` check internally. When then using it to only process a
specific type like this:
```
Iterator<Builder> iterator = builder.localMembersIterator;
while (iterator.moveNext()) {
Builder childBuilder = iterator.current;
if (childBuilder is SourceClassBuilder) {
// do something
}
}
```
we're doing two `is` checks, and also this - I think - reads easier:
```
Iterator<SourceClassBuilder> iterator = builder.localMembersIteratorOfType();
while (iterator.moveNext()) {
SourceClassBuilder childBuilder = iterator.current;
// do something
}
```
Change-Id: I6641343874ade3cf938aacc5dc0a7aa36bad9550
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/257361
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
This change adds logic to compute whether a pattern is refutable or
irrefutable, and reports the error `` if a refutable pattern is used
in an irrefutable context.
Additionally, the methods `handleConstOrLiteralPattern` and
`handleVariablePattern` are adjusted so that they report the static
type of the matcher back to the client.
A lot of internal type analysis logic previously referred to the
static type of a pattern as its "inferred type"; this nomenclature is
corrected to match the spec.
Change-Id: Icaa1118d1da41b28bea2b4f14c47578dacd85807
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256641
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
- Make previous behavior non-conditional
(already default and flag uses are removed)
- Use relative paths instead of package uris as module names
under --debugging-module-names flag, false by default.
(used as server paths in the browser, need to match relative
paths in source maps)
- Pass packageConfig to Javascript bundle API
- Add tests
Closes: https://github.com/dart-lang/sdk/issues/49667
Change-Id: I57c2e2629ba5dd756cce9a8ec6ae891fb092e1d9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/255826
Commit-Queue: Anna Gringauze <annagrin@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Weekly bot fails because of fuzz crashes on macros/scope_access which
crashes with this error:
weak suite stdout> Crashed with 'Bad state: Found 3 entries for file:///b/s/w/ir/cache/builder/sdk/pkg/front_end/testcases/macros/scope_access.dart::Class
weak suite stdout> ' when fuzz compiling.
weak suite stdout>
weak suite stdout> #0 ClosedWorldClassHierarchy.sanityChecks (package:kernel/class_hierarchy.dart:1046:21)
weak suite stdout> #1 ClosedWorldClassHierarchy.applyTreeChanges (package:kernel/class_hierarchy.dart:980:12)
weak suite stdout> #2 IncrementalCompiler._computeTransitiveClosure (package:front_end/src/fasta/incremental_compiler.dart:1759:15)
weak suite stdout> #3 IncrementalCompiler._calculateOutputLibrariesAndIssueLibraryProblems (package:front_end/src/fasta/incremental_compiler.dart:724:25)
weak suite stdout> #4 IncrementalCompiler.computeDelta.<anonymous closure> (package:front_end/src/fasta/incremental_compiler.dart:469:11)
As this area is in flux I've just marked them as crashing.
Change-Id: Ifb30d931c9097c04d227833722ff956619ea7b86
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256662
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Support for `when` clauses requires flow analysis integration, so that
`when` clauses can promote variables, e.g.:
f(int x, String? y) {
switch (x) {
case 0 when y != null:
// y is known to be non-null here
}
}
Support for labels in switch statements had a small flaw: we weren't
reporting an error in the case where a label shared a case body with a
pattern that tried to bind a variable, e.g.:
f(int x) {
switch (x) {
L: // Error: does not mind the variable `y`
case var y:
...
}
}
Change-Id: I0b2bb4721a6b3a8f7898df682b24b75ddb6e44ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256605
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
This change introduces the TypeAnalyzer methods
analyzeConstOrLiteralPattern, analyzeExpression,
analyzeInitializedVariableDeclaration, analyzeSwitchExpression,
analyzeSwitchStatement, analyzeUninitializedVariableDeclaration, and
analyzeVariablePattern. These are sufficient to analyze legacy switch
statements and legacy variable declarations, as well as switch
statements and switch expressions involving either constants or
variable patterns.
Although the code is not used in the analyzer or front end yet, it is
unit tested in isolation, and it's integrated into the existing flow
analysis unit tests.
A few minor tweaks had to be made to flow analysis to support this new
functionality. There should be no visible effect to existing analyzer
or front end behavior.
Change-Id: Ie8ec31ca92d5f2f7a7f6f6a20ca1baba3c6b28f9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256604
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This changes how scopes are computed for libraries and classes
(work on extensions is still pending). The change supports the new
shared scope need for augmentations, in which a declaration on the
origin or any of the augmentations is directly accessible in the
origin and all augmentations.
Change-Id: Ifb76f49bf80fcad2d92a0400b9be623406afb40d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/256262
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
Paul Berry