In https://dart-review.googlesource.com/c/sdk/+/468080, the private
implementation of the `DiagnosticCode` class was changed so that the
unique name of the error code is now stored in a field called
`_uniqueName`. (Previously it was stored in a field called
`uniqueName`. This inadvertently broke the
`use_literate_api_in_analyzer.dart` script. The fix is simple: change
`use_literate_api_in_analyzer.dart` to access the unique name using
the `_uniqueName` field.
Change-Id: I6a6a6964088b30506e52c1e1ae47c75293f5910c
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468902
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
All classes derived from `ClassMemberImpl` already had an
implementation of `augmentKeyword` except for
`PrimaryConstructorBodyImpl` (which was added as part of this CL).
In a follow-up CL, this will be used as part of a rewrite of
`MemberDuplicateDefinitionVerifier`, to allow members marked `augment`
to be excluded from duplicate checking.
Change-Id: I6a6a6964b8e41e3e5fde3e17428204d1e0898bbf
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468882
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Moves the logic for reporting `diag.enumConstantSameNameAsEnclosing`
and `diag.enumWithNameValues` out of
`MemberDuplicateDefinitionVerifier` and into `ErrorVerifier`. The
logic for detecting these diagnostics doesn't really make sense to be
part of `MemberDuplicateDefinitionVerifier`, because
`MemberDuplicateDefinitionVerifier` is concerned with detecting when a
class member has the same name as a previous member, whereas
`diag.enumConstantSameNameAsEnclosing` and `diag.enumWithNameValues`
are concerned with detecting when a class member has the same as the
class itself.
In a follow-up CL I intend to do a pretty substantial rewrite of
`MemberDuplicateDefinitionVerifier`. Moving this unrelated logic out
of `MemberDuplicateDefinitionVerifier` will make that rewrite more
straightforward.
Change-Id: I6a6a69645b1b3e5c4524d6de5816cb687b14994b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468841
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
In a follow-up CL I intend to do a pretty substantial rewrite of
`MemberDuplicateDefinitionVerifier`, but I plan to leave the rest of
`duplicate_definition_verifier.dart` mostly unchanged. Moving the code
that's changing to its own file should make the rewrite easier.
Change-Id: I6a6a69644f9cf661f0add8420f52bc659c2964e5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468840
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
It is not used; the `DuplicationDefinitionContext` is passed directly
from `LibraryVerificationContext` to
`MemberDuplicateDefinitionVerifier` by the static method
`MemberDuplicateDefinitionVerifier.checkLibrary`.
Change-Id: I6a6a6964b10e895eac4bf70706ab5b7b793886f4
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468560
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Changes the classes `InstanceElementImpl` and `InterfaceElementImpl`
to sealed classes. This helps avoid mistakes when switching on
variables of these types.
In a follow-up CL I intend to do a pretty substantial rewrite of
`MemberDuplicateDefinitionVerifier`. Making these classes sealed will
allow that rewrite to use `switch` expressions to decide which
diagnostic to report.
Change-Id: I6a6a6964c8e7d8c1a4478f45ff33fff4d77ea4db
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468860
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This change adds support for allowing for imports of unsupported
platform-specific libraries when the
`--include-unsupported-platform-library-stubs` flag is provided to the
CFE.
This flag sets the `includeUnsupportedPlatformLibraryStubs` property in
`TargetFlags`, which `Target`s can use to conditionally return different
`DartLibrarySupport` objects with different supported/unsupported
library sets.
A `checkForUnsupportedDartColonImports` function has been added to
`Target` that uses the value of `dartLibrarySupport` to determine if
there's any unsupported library imports. This function is called after
the various transformation operations provided by the `Target`
implementation, meaning the import of an unsupported library specified
in `dartLibrarySupport` will now result in a compilation error (this
includes `dart:mirrors` imports for VM targets when mirrors are
disabled, which was previously handled by the VM itself).
Related to https://github.com/dart-lang/sdk/issues/62125
TEST=Tests added / modified
Change-Id: Ife819b2e1a6d28f67d80aab6701cd23a1724aa4d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/465760
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Deprecates `DiagnosticCode.name` and
`diagnosticCode.uniqueName`. Clients should use
`DiagnosticCode.lowerCaseName` and
`DiagnosticCode.lowerCaseUniqueName` instead. This will ensure that
clients will compare diagnostic codes in case-insensitive fashion, as
the analyzer itself does.
In a future breaking change release of the analyzer, I will remove the
deprecated getters.
Change-Id: I6a6a69642f2d386546406d4af734808afec13e5e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468080
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Inform ASAN and MSAN about reads and writes through FFI pointers or external typed data. Previously we only informed MSAN about writes, which was enough to prevent false positives in foreign code, but gave false negatives for Dart code. This mostly uses the same machinery used for TSAN, and replaces some of the existing MSAN unpoison calls.
Also fixes some marshalling of compounds by value that generate loads extending past the end of the compound.
TEST=ci
Bug: https://github.com/dart-lang/sdk/issues/62221
Change-Id: Ia3573edb5a0aec32b6a57035a63e8f323a655ecc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/467401
Reviewed-by: Daco Harkes <dacoharkes@google.com>
Commit-Queue: Ryan Macnak <rmacnak@google.com>
Change the `test_runner` package's use of `DiagnosticCode.name` to
`DiagnosticCode.lowerCaseName`. There is no functional change since
all diagnostic codes generated by the analyzer are already in lower
case.
This helps pave the way for eventually deprecating and removing
`DiagnosticCode.name`, which will help ensure that analyzer clients
treat diagnostic codes in a case-insensitive fashion.
Change-Id: I6a6a69644898dff67a1f53dbe8c8a8cb757d2c96
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468121
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Bob Nystrom <rnystrom@google.com>
This format specifier does not perform a wide char to utf8 conversion
but rather a locale dependent wide char to multibyte conversion
(essentially wcstombs), which is not what this function is expecting
to do (it is expected to return utf8 encoded error message).
Issue https://github.com/dart-lang/sdk/issues/62252
TEST=not tested, speculative fix
Change-Id: Icd5ddbf9969dbd4acd2f7f48626ce0bd6a6a6964
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468800
Reviewed-by: Martin Kustermann <kustermann@google.com>
Commit-Queue: Slava Egorov <vegorov@google.com>
Runs either `dart pub get` or `gclient sync`, based on project type.
For the SDK, copies the .gclient and .gclient_entries files as well
into the parent dir.
Also adds a `--timeout` argument, controls how long to wait for analyzer messages.
Change-Id: Id2c28e6d0251e94914bb0650be104c1f90a66651
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468620
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Jake Macdonald <jakemac@google.com>
Auto-Submit: Jake Macdonald <jakemac@google.com>
Use a (mutable) global rather than a function to get the externref to
the appropriate module for exported function wrappers. This way we don't
have to make a slow JS interop call to get the module.
Recovers regression in golem "FunctionToJs.Convert.*.*" benchmarks seen
from introducing these functions.
Change-Id: Ie05d803a3d9992dce3dda89e6ae5af83d3f34383
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468220
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
This stops completion from suggesting `final` outisde a primary
constructor's parameter list when the feature is enabled. When the
feature is not enabled, it won't be suggested anywhere. I did that
because in the same release this CL is for we'll produce a warning if
`final` is used, and it seems unhelpful to suggest adding code that will
have a diagnostic associated with it.
Change-Id: I2f8ad2d92ea0641e2212c89d01aa23921b39b3e8
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468401
Reviewed-by: Samuel Rawlins <srawlins@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
This CL makes it possible for the Dart VM to start or stop `perf` while
doing GC, which gives a significantly more stable output.
Example usage:
Bash script that creates the correct file handles and calls dart under
`perf stat` based on the arguments given to the script:
```
DART=$1
shift
AOTSNAPSHOT=$1
shift
ctl_dir=/tmp/
ctl_fifo=${ctl_dir}perf_ctl.fifo
test -p ${ctl_fifo} && unlink ${ctl_fifo}
mkfifo ${ctl_fifo}
exec {ctl_fd}<>${ctl_fifo}
ctl_ack_fifo=${ctl_dir}perf_ctl_ack.fifo
test -p ${ctl_ack_fifo} && unlink ${ctl_ack_fifo}
mkfifo ${ctl_ack_fifo}
exec {ctl_fd_ack}<>${ctl_ack_fifo}
perf_ctl_fd=$ctl_fd perf_ctl_fd_ack=$ctl_fd_ack perf stat --delay=-1 --control fd:${ctl_fd},${ctl_fd_ack} -B -e "task-clock:u,context-switches:u,cpu-migrations:u,page-faults:u,cycles:u,instructions:u,branch-misses:u" $DART --perf_ctl_fd=${ctl_fd} --perf_ctl_fd_ack=${ctl_fd_ack} --perf_ctl_usage=1 --deterministic $AOTSNAPSHOT $@
exec {ctl_fd_ack}>&-
unlink ${ctl_ack_fifo}
exec {ctl_fd}>&-
unlink ${ctl_fifo}
```
This will start `perf stat` paused (which would require the run dart
aot-compiled script to start it when it wants to) and where the VM
pauses `perf` while doing GC.
In practise, looking at instruction counts reported by `perf stat`, I've
seen the difference between runs go from 2+ mio (and in some instances
23+ mio) to around 30,000 (!) on runs of the analyzer (tool
"stable_analysis").
TEST=manually
Change-Id: Iab955a5dd35e47f22c4f693ae50effc8ee633897
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468260
Reviewed-by: Slava Egorov <vegorov@google.com>
Commit-Queue: Jens Johansen <jensj@google.com>
This reduces main wasm module a bit (<1%) as it avoids the main module
from having to define and export simple accessor (e.g. field accessor)
functions.
There's two scenarios to consider:
Deferred module calls function from main module
=> No issues
Main module calls function from deferred module
=> This call must have been preceded by a CheckLibraryIsLoaded
=> The wasm modules of the deferred import must have been loaded
=> No issues.
We also change the inlining to be a little more conservative on static
field getters, as a static field may need to do a lazy initialized check
and call initializer function.
We also give the initializer function a better name.
Change-Id: I5d9b138c9fcb41f8580602fd1ba9ec5aa4af5341
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/467820
Commit-Queue: Martin Kustermann <kustermann@google.com>
Reviewed-by: Ömer Ağacan <omersa@google.com>
There was a bug in `CallTarget.signature` which triggers if there's only
one entry that's statically dispatched against, which causes us to
inline the polymorphic dispatcher, which relies on this (previously
incorrect) signature.
The CL also changes the dispatch table building logic to not allocate
table entries for the statically dispatched regions (as they would
never be used).
Change-Id: Ic2d0c387e8863e89ef811e1892642fe81df9189a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468000
Reviewed-by: Ömer Ağacan <omersa@google.com>
Commit-Queue: Martin Kustermann <kustermann@google.com>
We don't have a strict rule set for naming test methods, but the general
idea of grouping terms with underscores (and breaking an otherwise
rather universal rule of using camelCase) is to help to group like
test cases (aided by our alphabetical sorting enforcement).
There were examples in this file that really broke the grouping
mechanism by not using consistent grouping. Here are the broad strokes
of what I changed; no test bodies were changed, _only names_, but the
CL is hard to review because of sorting.
* `test_classGetterSetter_...` and `test_classSetter_...` were renamed
to use `class` as a group (`test_class_getterSetter_...` and
`test_setter_...`) consistently.
* `test_factoryConstructor_...` were renamed to use `constructor` as
the group base (`test_constructorFactory...`).
* `test_optionalParameter_...` were renamed to use `parameter` as the
group base (`test_paramter_...`). This is the bulk of the change.
There were previously dozens of tests starting with
`test_optionalParameter_` _and_ dozens of tests starting with
`test_parameter_`. However, `unused_element` only concerns itself
with optional parameters, so that can be the default meaning of
`test_parameter_`. (Similar to classes; we don't report any public
classes as unused, but we don't need to write `private` in every
test case.)
* In the parameter tests, there was an inconsistent placement of the
group `isUsed` or `notUsed`. It seems like the bulk of tests place
the `isUsed` or `notUsed` grouping earlier rather than at the end of
the test name, so I went with that for this consistency CL.
Change-Id: I54be6591615d015ae9cf87ee4c9726ed7cfee209
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468180
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Paul Berry <paulberry@google.com>
Change the `verify_docs` package's use of `DiagnosticCode.name` to
`DiagnosticCode.lowerCaseName`. There is no functional change since
all diagnostic codes generated by the analyzer are already in lower
case.
This helps pave the way for eventually deprecating and removing
`DiagnosticCode.name`, which will help ensure that analyzer clients
treat diagnostic codes in a case-insensitive fashion.
Change-Id: I6a6a69645300e89b1bed342804d5e89ae9cf556b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468141
Reviewed-by: Nate Bosch <nbosch@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
This adds completion support in the class header. Support for completion
in the body will be added in a separate CL.
Please look carefully at the tests to ensure that there aren't holes in
the coverage.
Change-Id: I189f25fbb90f43b4d8993622d5eb025d3160bef1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/467920
Reviewed-by: Kallen Tu <kallentu@google.com>
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Converts the code that reports diagnostic codes
`bodyMightCompleteNormally` and `bodyMightCompleteNormallyNullable` to
use the literate diagnostic reporting API.
This was not a straightforward conversion because the code for
reporting these diagnostics
(`ResolverVisitor.checkForBodyMayCompleteNormally`) made use of the
`DiagnosticReporter.atConstructorDeclaration` method, which doesn't
have a direct analogue in the literate diagnostic API. The equivalent
formulation in the literate diagnostic API is to call
`ConstructorDeclarationExtension.errorRange` to compute the offset and
length for the constructor name, and then pass the result to
`LocatableDiagnostic.at`.
Note that the previous version of
`ResolverVisitor.checkForBodyMayCompleteNormally` used an `if`/`else`
chain to handle three possible types for `errorNode`:
`ConstructorDeclaration`, `Token`, or `BlockFunctionBody`. But the
call sites might pass in any sort of `FunctionBody`. So it appeared
that the diagnostic would be accidentally dropped in the case where
`errorNode` was some other type of `FunctionBody`. However, it turns
out that there was a tricky reason why the diagnostic was never
accidentally dropped: the call site that passes in a `FunctionBody`
also passes the same `FunctionBody` for the `body` parameter, and
`ResolverVisitor.checkForBodyMayCompleteNormally` only checks for
`bodyMightCompleteNormally...` errors if `body` is of type
`BlockFunctionBody`.
In the new code, a `switch` expression is used to compute the range
over which the diagnostic should be reported, so it is manifestly
clear that the diagnostic is never accidentally dropped.
Change-Id: I6a6a69647a8fd1928d935ec8b5cb0c733ad2412f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/467540
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Fixes https://github.com/dart-lang/sdk/issues/62214
Danny describes the problem at a high level in https://github.com/dart-lang/sdk/issues/62214.
At a lower level, the issue is that we add the new `PluginIsolate` to
the `_pluginMap` as soon as we instantiate it! Before we've even made
the request to start it up. The `_pluginMap` is how PluginManager sends
out various requests, like watch events, priority files, and update
content.
The fix is easy enough: we wait to add the PluginIsolate to the `_pluginMap` until after we've awaited `PluginIsolate.start`.
Change-Id: I05e6314fde10fbaf4cf25b38b526c5cf96bd65ae
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/467923
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This response header entry prevents DevTools from being embedded in
iframes, which is needed to embed the DevTools inspector within the
Flutter widget preview environment.
TEST=Manually verified with `flutter widget-preview start`
Change-Id: Ic4ec3cf0e23509a6c0cbc94ab636a18c6abf733f
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468020
Auto-Submit: Ben Konyi <bkonyi@google.com>
Reviewed-by: Nicholas Shahan <nshahan@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
This will allow diagnostic reporting code in the analyzer to be more
easily converted to the new literate diagnostic reporting API, because
it will make it possible to use `SourceRange` as the common
denominator for situations where the location where a diagnostic needs
to be reported might come from either a `SyntacticEntity` or a
`SourceRange`.
Change-Id: I6a6a6964f3ec2ea33e8900d93b5abe714c9e1dcc
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/467682
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Johnni Winther <johnniwinther@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
`builder.current` at the time of creating the labelGraph is the block
after the body. So setting that as the end node of the subGraph was
including all the code after loop into the body of the labeled
statement.
Instead we use the `bodyBlock` as the end of the labelGraph as this is
the last block in the body of the loop. If no such body exists, we use
the `conditionEndBlock` which is the block right before the body (and
still includes the logic to exit the loop).
Also changes codegen to not emit a labelStatement if it has no body.
AFAICT we don't do DCE on flow blocks so codegen is the best time to
avoid emitting this code.
Bug: https://github.com/dart-lang/sdk/issues/62185
Change-Id: Ia80cc7d3b44782c6193a67e8adbbc66f00b8f133
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/468060
Commit-Queue: Nate Biggs <natebiggs@google.com>
Reviewed-by: Sigmund Cherem <sigmund@google.com>
Ryan Macnak