This updates the exhaustiveness checking to return the shortest witness when no more cases match a value.
This also fixes an exponential case that occurred when checking for reachability.
Closes#59927
Change-Id: I82ede75113ca5d361875620287f7ce3c5fb2f5d2
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/405120
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
The constructors for `SharedTypeView<TypeStructure>` and
`SharedTypeSchemaView<TypeStructure>` are changed so that they accept
`TypeStructure` rather than `SharedTypeStructure<TypeStructure>`.
For context, I'm currently in the middle of migrating the analyzer so
that it passes a type argument of `TypeImpl` instead of `DartType`
when using generic types that accept a `TypeStructure` type
argument. The purpose of this change is to ensure that when a given
use of `SharedTypeView` or `SharedTypeSchemaView` has its type
argument changed to `TypeImpl`, the type checker will ensure that the
corresponding constructor argument satisfies `TypeImpl`.
There is no change to runtime behavior.
Change-Id: I34d540312b567e390e7dfa535806051e0d5f2868
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/404900
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Extension methods can no longer be disabled. This CL removes the option
from the scanner config and the parser related specific recovery.
It also removes any specific (triggered) test of the functionality.
A follow-up CL will do the same for NNBD.
Change-Id: Ia385008e5ed1333fb37697b8fe424b8759bce198
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/403581
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
The following shared getters are renamed so that their names are
distinct from the corresponding getters in the analyzer:
- `SharedFunctionTypeStructure.positionalParameterTypes` is renamed to
`positionalParameterTypesShared` to be distinct from the analyzer's
public getter `FunctionType.positionalParameterTypes`.*
- `SharedFunctionTypeStructure.returnType` is renamed to
`returnTypeShared` to be distinct from the analyzer's public getter
`FunctionType.returnType`.
- `SharedNamedFunctionParameterStructure.type` is renamed to
`typeShared` to be distinct from the analyzer's public getter
`FormalParameterElement.type`.
- `SharedNamedTypeStructure.type` is renamed to `typeShared` to be
distinct from the analyzer's public getter
`RecordTypeNamedField.type`.
- `SharedRecordTypeStructure.positionalTypes` is renamed to
`positionalTypesShared` to be distinct from the analyzer's public
getter `RecordType.positionalTypes`.*
- `SharedRecordTypeStructure.sortedNamedTypes` is renamed to
`sortedNamedTypesShared` to be distinct from the analyzer's public
getter `RecordType.sortedNamedTypes`.
- `SharedTypeParameterStructure.bound` is renamed to `boundShared` to
be distinct from the analyzer's public getter
`TypeParameterElement2.bound`.
*Note that `FunctionType.positionalParameterTypes`,
`RecordType.positionalTypes`, and `RecordType.sortedNamedTypes` were
unintentionally exposed as part of the analyzer's public API. In a
previous CL I marked them as deprecated.
These renames pave the way for changing the analyzer's `DartType`
class so that it implements `SharedTypeStructure<TypeImpl>` rather
than `SharedTypeStructure<DartType>` (without the renames, the public
getters mentioned above would all have to be changed to have type
`TypeImpl`, and that in turn would expose `TypeImpl` through the
analyzer public API, which we don't want to do).
Once `DartType` implements `SharedTypeStructure<TypeImpl>`, that will
allow all the other uses of `SharedTypeStructure<DartType>` in the
analyzer to be gradually migrated to
`SharedTypeStructure<TypeImpl>`. Once that is done, `DartType` can be
changed so that it no longer implements
`SharedTypeStructure<TypeImpl>` at all (`TypeImpl` will implement
`SharedTypeStructure<TypeImpl> instead). This will free us up to make
future changes to the `SharedTypeStructure` base class without
inadvertently exposing those changes through the analyzer public API.
This is part of a larger arc of work to change the analyzer's use of
the shared code so that the type parameters it supplies are not part
of the analyzer public API. See
https://github.com/dart-lang/sdk/issues/59763.
Change-Id: I0686fdeae304f8948484516f0249841b79e7da6c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/403625
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
The following shared getters are renamed so that their names are
distinct from the corresponding getters in the analyzer:
- `SharedFunctionTypeStructure.sortedNamedParameters` is renamed to
`sortedNamedParametersShared` to be distinct from the analyzer's
getter `FunctionTypeImpl.sortedNamedParameters`.
- `SharedFunctionTypeStructure.typeFormals` is renamed to
`typeParametersShared` to be distinct from the analyzer's getter
`FunctionTypeImpl.typeFormals`.
- `SharedNamedFunctionParameterStructure.name` is renamed to
`nameShared` to be distinct from the analyzer's getter
`ParameterElement.name`.
- `SharedNamedTypeStructure.name` is renamed to `nameShared` to be
distinct from the analyzer's getter `RecordTypeNamedFieldImpl.name`.
These renames pave the way for switching the analyzer's use of these
shared types over to the new element model. They're necessary because
when the analyzer switches over to the new element model:
- `FunctionTypeImpl.sortedNamedParameters` will no longer have the
correct type to override
`SharedFunctionTypeStructure.sortedNamedParameters`; instead, it
will be necessary to convert each named parameter to a corresponding
element in the new element model (`FormalParameterElementImpl` or
`ParameterMember`).
- `FunctionTypeImpl.typeFormals` will no longer have the correct type
to override `SharedFunctionTypeStructure.typeParametersShared`;
instead, it will be necessary to use
`FunctionTypeImpl.typeParameters` (which is a list of
new element model type parameters).
- `ParameterElementMixin` will no longer implement
`SharedNamedFunctionParameterStructure`; instead,
`FormalParameterElementImpl` and `ParameterMember` (which are
classes in the new element model) will implement it. The class
`FormalParameterElementImpl` deliberately doesn't have a `name`
getter; instead it has a `name3` getter, with slightly different
semantics (it returns `null` rather than the empty string when there
is no name).
Change-Id: I629e45b6fc588e6a86f7590aab853064e31ab661
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/402220
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This change simplifies working with `@Native`-annotated functions by allowing the native type to be omitted when it can be inferred from the Dart function's signature. While this was previously supported for `@Native` fields, it now applies to functions as well.
Before this change, you needed to specify the native type explicitly:
```
@Native<Void Function(Pointer)>()
external void free(Pointer p);
```
After this change, the native type can now be omitted if it's clear from the Dart signature:
```
@Native()
external void free(Pointer p);
```
TEST=tests/ffi/native_assets/*
CoreLibraryReviewExempt: VM only
Closes: https://github.com/dart-lang/sdk/issues/54810
Change-Id: Ied5407fcd2f49d85284cb7817f0c8cad2a73626b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/400840
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Daco Harkes <dacoharkes@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Moritz Sümmermann <mosum@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Change the analyzer's use of the following shared classes and mixins
to supply `PromotableElement2` instead of `PromotableElement` as the
type parameter that represents promotable variables:
- `AssignedVariables`
- `AssignedVariablesForTesting`
- `CaseHeadOrDefaultInfo`
- `DemoteViaExplicitWrite`
- `FlowAnalysis`
- `GeneratedTypeConstraint`
- `MatchContext`
- `MergedTypeConstraint`
- `NonPromotionReasonVisitor`
- `SwitchExpressionMemberInfo`
- `SwitchStatementMemberInfo`
- `TypeAnalyzer`
- `TypeAnalyzerErrors`
- `TypeAnalyzerOperations`
- `TypeAnalyzerOperationsMixin`
- `TypeConstraintFromArgument`
- `TypeConstraintFromExtendsClause`
- `TypeConstraintFromFunctionContext`
- `TypeConstraintFromReturnType`
- `TypeConstraintGenerator`
- `TypeConstraintGeneratorMixin`
- `TypeConstraintOrigin`
- `UnknownTypeConstraintOrigin`
- `VariableBinder`
- `VariableBinderErrors`
This ensures that all references to variables within the shared code
are using the new analyzer element model.
As a result of this type change, a lot of analyzer code that
interfaces with shared logic needs to change to use the new element
model.
Also, a few additional members need to be added to
`BindPatternVariableElementImpl2`, `JoinPatternVariableElementImpl2`,
`LocalVariableElementImpl2`, and `PatternVariableElementImpl2` to
allow members of the underlying `_wrappedElement` to be accessed.
Change-Id: Ie925eeb82523c769c4d869a37551718f75d334ca
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/400660
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This change introduces a new mixin, `NullShortingMixin`, with a type
parameter `Guard` for the data structure used by the client to desugar
null-aware accesses. The mixin maintains a stack of these guards, and
provides methods that the client can use to manipulate the stack:
- `startNullShorting` adds an entry to the stack; it should be called
when the client encounters the `?.` part of a null-aware expression.
It also provides two hooks that the client can override if desired:
- `handleNullShortingStep`, called whenever an entry is removed from
the stack; this will let the CFE know when it should de-sugar a null
short using a "let" expression.
- `handleNullShortingFinished`, called whenever a sequence of entries
is removed from the stack; this will let the analyzer know when it
should change the static type of an expression as a result of
null-shorting.
Also, a new optional parameter, `continueNullShorting`, is added to
`TypeAnalyzer.analyzeExpression`. If this parameter is `false` (the
default value), then any null shorting that is started during analysis
of the expression (due to the client calling `startNullShorting`) will
be terminated before returning. If it is `true`, then null shorting
won't be terminated, so it will extend to the containing
expression. For expression types that are able to extend null shorting
that appears in their target subexpression (e.g., method calls and
property accesses), the `visit` or `analyze` method should pass
`false` for this parameter when making a recursive call to analyze the
target.
Finally, the `NullShortingMixin` has a getter `nullShortingDepth`,
that `TypeAnalyzer.analyzeExpression` uses to determine when null
shorting should be terminated, and a method `finishNullShorting`, that
actually does the work of terminating null shorting. In principle,
clients don't need to invoke these parts of the `NullShortingMixin`
API. However, since the CFE doesn't always use
`TypeAnalyzer.analyzeExpression` (favoring its own internal methods
`InferenceVisitorImpl.inferExpression` and
`InferenceVisitorImpl.inferNullAwareExpression`), the CFE will need to
use them.
The "mini_ast" tests of flow analysis formerly used a method called
`nullAwareAccess` to exercise the flow analysis effects of null-aware
constructs. This was hacky and confusing, and is now unnecessary,
since the shared infrastructure now fully supports null-shorting. So
this method has been removed and replaced by the ability to mark a
method invocation or property access as null-aware.
This change only builds the infrastructure for shared analysis of
null-shorting; the analyzer and CFE still handle null shorting on
their own. In follow-up CLs I will change the analyzer and CFE to make
use of the shared mechanism.
Change-Id: Ide25a915c4d06eab751b87c1c2745749d23a8114
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/399480
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
When `PrefixedIdentifierResolver.resolve` rewrites a prefixed
identifier expression to a property access (which it does when the
prefix is an expression having record type), instead of making a call
from `ResolverVisitor.visitPropertyAccess` to
`ResolverVisitor.visitPropertyAccess` to resolve the rewritten
expression, use a private helper method for both code paths.
This ensures that all `visit` methods in the `ResolverVisitor` are
called solely from `ExpressionImpl.accept` or from
`ExpressionImpl.resolveExpression` (at least as far as expressions are
concerned). This will pave the way for a follow-up CL, in which I will
make sure that all expression resolution is done through the
`TypeAnalyzer.analyzeExpression` method. That will in turn allow the
analyzer to use the shared implementation of null-shorting introduced
in https://dart-review.googlesource.com/c/sdk/+/399480.
Change-Id: I782e10be2f58fdc0991b6d917f81bedd856485a9
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/399627
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Autogenerated files was formatted with the new style, so if one for
instance formatted the file via the IDE or by saying
`out/ReleaseX64/dart-sdk/bin/dart format pkg/front_end/lib/` we'd get
*a lot* of changes which isn't great.
This CL sets the formatter version for the auto-generated files,
hopefully avoiding such things.
Change-Id: I4f92aafde7c77e7c78179f78bf821979a25ec12c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/398884
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This is the shared base class for all representations of the type
`Null`. This allows the shared codebase to use `is` tests to tell when
a type is `Null`.
Change-Id: I98059b60c7eaab9c9f1e3f7addb7913dffc9cf9d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/396380
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This CL removes the unnecessary conversion from `TypeStructure` types
to `SharedTypeView` and `SharedTypeSchemaView` and back. By design,
the shared constraint generation method is operating on
`TypeStructure` types and uses the shared procedures named with the
'Internal' suffix to transform those types. In this CL the shared
procedures that are only used in the shared constraint generation
method or in 'Internal' procedures are converted to 'Internal'
themselves, and the corresponding update in the parameters accepted
and returned by those procedures is made.
Part of https://github.com/dart-lang/sdk/issues/54902
Change-Id: Ic8596b342bde7e78093e990fc0f12f705ff6dee1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/395962
Commit-Queue: Chloe Stefantsova <cstefantsova@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
With 0ca1ff2281 fixing the reason why we
had `isA2` we can get rid of it. One 100-run-each-benchmark of compiling
a fixed version of the CFE with the current version of the CFE I get
```
msec task-clock:u: -0.3133% +/- 0.2298% (-13.22 +/- 9.70)
cycles:u: -0.4109% +/- 0.2303% (-71702583.62 +/- 40176749.86)
instructions:u: -0.0150% +/- 0.0002% (-3206465.75 +/- 50567.00)
branch-misses:u: -0.9597% +/- 0.8046% (-615355.48 +/- 515877.98)
seconds time elapsed: -0.3138% +/- 0.2297% (-0.01 +/- 0.01)
seconds user: -0.2991% +/- 0.2978% (-0.01 +/- 0.01)
```
(the only real thing to look at here is likely the `instructions:u`
going down by ~3.2 mio.)
For anyone interested:
Manualy testing what 0ca1ff2281 did vs
the commit before (by running it 5 times each by hand through perf stat)
I get
instructions:u: -0.0831338% +/- 0.00115149% (-1.78503e+07 +/- 247246)
(i.e. almost 18 mio less instructions).
Change-Id: I01600c33364933da262b3354298255e8b2df8afb
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/394101
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This adds support for replacement a [StaticGet] with the constant
initializer of the referenced constant during evaluation of macro
metadata. Currently constants defined in the same library or
compilation is supported. For full support the constant initializers
need to be included in the outlines/summaries.
Change-Id: I219f85dded63342d4e3f957f0b7321badbe376a4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/392907
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Jens Johansen <jensj@google.com>
I'm still chasing down a couple of google3 failures, but this is ready for review so that I can get it approved and land it once the last couple of failures are fixed. Here is who I think should review what:
athom@ for:
- DEPS
johnniwinther@ for:
- pkg/_fe_analyzer_shared
- pkg/front_end
- pkg/kernel
brianwilkerson@ for:
- pkg/analysis_server
- pkg/analyzer_plugin
- pkg/analyzer_utilities
kenzieschmoll@ for:
- pkg/dartdev
pquitslund@ for:
- pkg/linter/lib/src/lint_codes.g.dart
If you're not the right person, feel free to summon someone else.
Most of the changes here are re-running code generators that auto-format the code they generate. The changes are:
Roll in the latest dart_style commit:
- DEPS
Manually updated these test expectations to expect the new style:
- pkg/analysis_server/test/lsp/format_test.dart
- pkg/analysis_server/test/services/refactoring/agnostic/change_method_signature_test.dart
- pkg/analysis_server/test/src/domains/flutter/set_property_value_test.dart
- pkg/analysis_server/test/src/services/flutter/container_properties_test.dart
- pkg/analysis_server/test/src/services/flutter/widget_descriptions_test.dart
- pkg/analysis_server/test/src/services/refactoring/convert_selected_formal_parameters_to_named_test.dart
- pkg/analysis_server/test/src/services/refactoring/move_selected_formal_parameters_left_test.dart
This was auto-generated by something, but I'm not sure why it thinks there is a diff:
- pkg/analyzer_plugin/doc/api.html
Updated to require a version of dart_style that accepts a language version in DartFormatter():
- pkg/analyzer_plugin/pubspec.yaml
Updated to always use the latest language version (and thus new style) when invoking the formatter:
- pkg/analyzer_utilities/lib/tools.dart
Manually updated the formatting in the code templates so that they matched the formatting expected by the tests, which implicitly format using the latest language version:
- pkg/dartdev/lib/src/templates/...
The rest are all generated files that are formatted so re-generated using the new style:
- pkg/_fe_analyzer_shared/lib/src/experiments/flags.dart
- pkg/_fe_analyzer_shared/lib/src/messages/codes_generated.dart
- pkg/analysis_server_client/lib/handler/notification_handler.dart
- pkg/analysis_server_client/lib/src/protocol/...
- pkg/analysis_server/lib/protocol/protocol_generated.dart
- pkg/analysis_server/test/integration/support/integration_test_methods.dart
- pkg/analysis_server/test/integration/support/protocol_matchers.dart
- pkg/analyzer_plugin/lib/protocol/...
- pkg/analyzer_plugin/test/integration/support/integration_test_methods.dart
- pkg/analyzer_plugin/test/integration/support/protocol_matchers.dart
- pkg/analyzer/lib/src/analysis_options/error/option_codes.g.dart
- pkg/analyzer/lib/src/dart/error/...
- pkg/analyzer/lib/src/error/codes.g.dart
- pkg/analyzer/lib/src/manifest/manifest_warning_code.g.dart
- pkg/analyzer/lib/src/pubspec/pubspec_warning_code.g.dart
- pkg/analyzer/lib/src/summary/format.dart
- pkg/analyzer/lib/src/wolf/ir/ir.g.dart
- pkg/compiler/test/tool/graph_isomorphizer/golden/less_simple/lib_000_1.dart
- pkg/compiler/test/tool/graph_isomorphizer/golden/less_simple/lib_001_0.dart
- pkg/compiler/test/tool/graph_isomorphizer/golden/less_simple/lib_010_0.dart
- pkg/compiler/test/tool/graph_isomorphizer/golden/less_simple/lib_100_0.dart
- pkg/compiler/test/tool/graph_isomorphizer/golden/simple/...
- pkg/front_end/lib/src/api_prototype/experimental_flags_generated.dart
- pkg/front_end/lib/src/codes/cfe_codes_generated.dart
- pkg/front_end/lib/src/util/parser_ast_helper.dart
- pkg/front_end/test/parser_test_listener.dart
- pkg/front_end/test/parser_test_parser.dart
- pkg/front_end/testcases/...
- pkg/kernel/lib/src/coverage.dart generated
- pkg/kernel/lib/src/equivalence.dart generated
- pkg/linter/lib/src/lint_codes.g.dart
Change-Id: Ice0141b763e63b84f54692cd19a442a0719673c6
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/391263
Commit-Queue: Bob Nystrom <rnystrom@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Phil Quitslund <pquitslund@google.com>
Before, when parsing a new style typedef without an identifier (e.g.
`typedef = whatnot`) it concluded that the token after the equal-sign
wasn't an equal sign an that it thus had to be an old style typedef,
followed by recovery there.
This CL makes the recovery insert an identifier after `typedef` (what
the recovery of the old style actually did too), and then parse it as a
new style typedef.
This causes the previous many errors to just be `Expected an identifier,
but got '='.`
It is furthermore verified that the parsing of such a case is ~the same
as when having an indentifier.
Fixes https://github.com/dart-lang/sdk/issues/56912
Change-Id: I5cde1f29839555b1d6027a7d040dc6f60ac614a5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/392560
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
The exhaustiveness model relies on null being extracted from nullable, for instance modeling `int?` as `int|Null`. This failed on type variable that are potentially nullable but not explicitly nullable. For these `Null` should be extract from their bound and not from themselves.
The logic in the getStaticType method now uses `isNullable` to determine both when to extract and to combine, so to avoid extracting but not combining `Null` for type variables and also not combine but not extract for instance for `void`.
Closes#56998
Change-Id: I47c2d0d6535ca66fe00e6344b11550c4308a7388
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/392944
Reviewed-by: Chloe Stefantsova <cstefantsova@google.com>
Commit-Queue: Johnni Winther <johnniwinther@google.com>
Mohamed Abdelaal