This change removes support for external strings from the VM along with
Dart_NewExternalLatin1String, Dart_NewExternalUTF16String and
Dart_IsExternalString Dart C API functions.
External strings are not used by the VM nor any known embedder, but
Dart VM was paying the maintenance and performance price for
the external string implementation classes.
TEST=ci
Change-Id: I094cd2d2b7ec0840e9f09e1ca9e5a7acd4e78c28
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358760
Reviewed-by: Ryan Macnak <rmacnak@google.com>
Reviewed-by: Siva Annamalai <asiva@google.com>
Commit-Queue: Alexander Markov <alexmarkov@google.com>
Now that null contexts are impossible during analyzer resolution
(https://dart-review.googlesource.com/c/sdk/+/357522), it's possible
to make a lot of variables, fields and parameters that represent
contexts non-nullable.
This change propagates non-nullability of contexts through the
analyzer to the extent that can be done reasonably quickly and
safely. In particular, it makes the following changes:
- It changes the following helper methods so that they no longer
accept a `null` context:
- TypeSystemImpl.acceptsFunctionType
- TypeSystemImpl.refineNumericInvocationContext
- TypeSystemImpl.setupGenericTypeInference
- TypeSystemImpl._refineNumericInvocationContextNullSafe
- InvocationInferenceHelper.inferTearOff
- InvocationInferenceHelper.resolveMethodInvocation
- ElementResolver.visitMethodInvocation
- ErrorDetectionHelpers.getImplicitCallMethod
- ResolverVisitor.insertGenericFunctionInstantiation
- ResolverVisitor._insertImplicitCallReference
- ResolverVisitor._resolveRewrittenFunctionExpressionInvocation
- StaticTypeAnalyzer.visitConditionalExpression
- StaticTypeAnalyzer.visitIntegerLiteral
- AstResolver.resolveExpression
- It changes the following classes so that their `resolve` methods no
longer accept a `null` context (nor do the methods that those
`resolve` methods defer to):
- AssignmentExpressionResolver
- BinaryExpressionResolver
- ConstructorReferenceResolver
- FunctionExpressionInvocationResolver
- FunctionExpressionResolver
- InstanceCreationExpressionResolver
- MethodInvocationResolver
- PostfixExpressionResolver
- PrefixExpressionResolver
- PrefixedIdentifierResolver
- RecordLiteralResolver
- SimpleIdentifierResolver
- TypedLiteralResolver
- It changes all the classes in the `InvocationInferrer` class
hierarchy so that they no longer accept a `null` context.
- It changes the following helper methods so that they no longer
return a `null` context:
- AssignmentExpressionResolver._computeRhsContext
- InvocationInferrer._computeContextForArgument
- MethodInvocationInferrer._computeContextForArgument
- YieldStatementResolver._computeContextType
- It changes PropertyElementResolverResult.indexContextType so that it
no longer can be `null`.
- It ensures that the analyzer always passes a non-null context to the
_fe_analyzer_shared method `TypeAnalyzer.analyzeExpression`. This
will pave the way for a follow-up CL that makes that method stop
accepting `null`.
In many cases, to accomplish this, it was necessary to make explicit
use of the unknown type schema `_`
(UnknownInferredType.instance). Although adding these explicit uses
makes the code a bit more verbose, it's not really fundamentally more
complex than it was before; previously, the code used `null` to
represent `_` in these cases (sometimes implicitly).
Change-Id: I1479e7c59969c59ea67abef30daa6a516b15ed97
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358662
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
As noted by Lasse, we're not really consistent and the singular is more "correct".
See: 71456592d0 (r140033857)
Change-Id: I55afeab8c42d9f20999e263682f71d54a2302ea5
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358682
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Phil Quitslund <pquitslund@google.com>
The analyzer's mechanism for passing contexts down the stack while
recursively resolving expressions is to add an optional `contextType`
parameter to some of the `visit` methods in `ResolverVisitor`. This
parameter is only included in `visit` methods that would actually use
it (e.g. `visitDoubleLiteral` doesn't have it, since the analysis of a
double literal doesn't depend on the context).
When the resolver needs to analyze a subexpression, if it needs to
supply a context, it uses `ExpressionImpl.resolveExpression` to
dispatch to the appropriate `visit` method; this passes the context
along to the optional `contextType` parameter. If, on the other hand,
it **doesn't** need to supply a context, it uses the standard
AstVisitor mechanism, which dispatches to the `visit` method without
supplying a context type, so the `contextType` parameter takes on its
default value.
Previous to this CL, the default value of each `contextType` parameter
was `null`; this had the unintended consequence of making a
distinction between a `null` context and a context of `_`
(`UnknownInferredType.instance`). The front end, by contrast, has a
visitor paradigm that allows passing a required argument through to
the `visit` method, so its context parameters are all non-nullable,
and it makes no such distinction.
Prior to addressing language issue 3648
(https://github.com/dart-lang/language/issues/3648), the difference
was only observable for `await` expressions. Now that that issue has
been addressed, there is no user-visible difference between `_` and
the null context. But it's easy to imagine a difference accidentally
sneaking in during future development.
To avoid future bugs, this change makes `_` the default value for each
`contextType` parameter. To do this, it was necessary to change
`UnknownInferredType.instance` from a final variable to a const.
To the best of my knowledge, this change should have no user-visible
effect.
Bug: https://github.com/dart-lang/language/issues/3648
Change-Id: Id74a513366831239df2d56ceac57c2dbe5c5084e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/357522
Commit-Queue: Paul Berry <paulberry@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
In the front end, type inference of an expression always takes place
with respect to a type schema (the "context"). In the analyzer, type
inference of an expression sometimes takes place with respect to a
context, but sometimes takes place with respect to no context at all;
the latter circumstance arises when the analyzer uses its standard
AstVisitor mechanism to call one of the visit methods in the
ResolverVisitor class, and so the visit method's contextType argument
takes on the value null. Because of this I am calling this situation a
"null context".
In all the circumstances where the analyzer infers an expression using
a null context, the front end infers the same expression using a
context of _. Furthermore, prior to this change, all but one of the
analyzer's visit methods treated a null context the same as they
treated a context of _. The one exception was visitAwaitExpression: in
this method, if the context was the null context, then the analyzer
analyzed the await expression's subexpression using a context of _;
otherwise, it analyzed it using a context of FutureOr<_>. Whereas the
front end, lacking any notion of a "null context", analyzes the await
expression's subexpression using a context of FutureOr<_> in the same
circumstances.
This change brings the analyzer behavior into line with the front end.
Fixes https://github.com/dart-lang/language/issues/3648.
Bug: https://github.com/dart-lang/language/issues/3648
Change-Id: Ifd77988010d4387ce48eaa20dff4356beec03753
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/357521
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Paul Berry <paulberry@google.com>
Change-Id: Icc4b89f1b25dd633279d87e9d51f85372d962c7b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358450
Commit-Queue: Erik Ernst <eernst@google.com>
Reviewed-by: William Hesse <whesse@google.com>
`CorrectionUtils.findPossibleLocalVariableConflicts` actually does not
use the `eol` utility or the `_buffer` field; it turns out it is a
good candidate for an extension method on CompilationUnit. It is moved
to the existing extension.
In refactoring call sites, PostfixCompletionProcessor didn't have a
perfectly obvious CompilationUnit field, so I refactored it a bit, and
cleaned up it's fields:
* Make the class final.
* Rename `NO_COMPLETION` to `_noCompletion`
* Privatize `node`, `completion`, `eol`, `file`, `key`,
`selectionOffset`, `typeProvider`, and `typeSystem`.
* While checking whether `change`, `linkedPositionGroups`, and
`exitPosition` could be private, it turns out they are unused; this
would have been flagged by static analysis if they had been private.
Change-Id: I29c48c362261b11402cee43464386c3152df7158
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358641
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Adds support for 4.15 of the VM service protocol to both packages. Also
adds `yieldControlToDDS` to the `VmServiceInterface` so implementers of
the service protocol can correctly handle DDS connections.
Change-Id: I9253a647c1781f4d52758ecce4984082dfbf4fa0
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/357720
Reviewed-by: Derek Xu <derekx@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Elliott Brooks <elliottbrooks@google.com>
Previously I had shared logic in a base reflective test class. This made marking tests (in the base class) as failing difficult.
This just migrates the shared logic to mixins. No test logic is changed.
Do note that the mixins are temporary. When we enable multi-option contexts they will be deleted.
Change-Id: I22f6651a79b6ccc125fb97dc2a0dbc2efa86fe6d
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358327
Commit-Queue: Phil Quitslund <pquitslund@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
This changes Go-to-Super to handle augmentations (jumping to a super-member will go the last augmentation in the chain) and constructors (will jump to the actual super constructor that is called, regardless of name).
Change-Id: I7439fd42ef81983e7a052f250f7ba272fe8c2c86
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/357608
Commit-Queue: Brian Wilkerson <brianwilkerson@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Change-Id: Ieff638aee139d6ebb1b0fb98444331d115eb91d1
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358503
Reviewed-by: Alexander Markov <alexmarkov@google.com>
Commit-Queue: Ben Konyi <bkonyi@google.com>
Reviewed-by: Alexander Thomas <athom@google.com>
The big one is `getIndent`, which I think can be simpler, and also used a handwritten implementation of `String.operator *`. It turns out:
* > 90% of calls to `getIndent` were `getIndent(1)`, which can be
replaced with a constant `' '`.
* Then 4 calls to `getIndent` were `getIndent(2)`, which can be replaced
with a constant `' ' + ' '`.
* Then one last call, in CorrectionUtils itself, used a variable number
of indents which can be replaced with `' ' * n`. This is in the
`indentRight` function.
Also:
* Privatize `getInsertionLocationTop`, `isClassWithEmptyBody`, `isJustWhitespaceOrComment`, `skipEmptyLinesLeft`
* Rewrite CorrectionUtils.findSimplePrintInvocation as an extension
method on AstNode; does not need the `_buffer`.
Change-Id: I15c19b8c0cc354adcd4ffea5803b3a182cf28336
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358400
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Samuel Rawlins <srawlins@google.com>
Reviewed-by: Konstantin Shcheglov <scheglov@google.com>
Resident runner used to look either for pubspec.yaml
or .dart_tool/package_config.json to find package root.
However it does not make much sense to look for pubspec.yaml
you can't resolve packages using just pubspec anyway - you
need package_config.json. This was making it impossible
to use resident runner with packages in Dart SDK checkout:
each package contains pubspec.yaml, but package_config.json
is generated at the root of SDK checkout instead.
This CL also removes support for .packages file - we have
deprecated and removed this file in 2022.
R=kustermann@google.com
TEST=manually
Change-Id: I18ce7a1a82bc72bbc944d8ab2d40f40cdb15cc1e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/357620
Commit-Queue: Slava Egorov <vegorov@google.com>
Reviewed-by: Martin Kustermann <kustermann@google.com>
The class modifiers feature specification was updated such that mixins
cannot be `sealed`, and several other combinations were eliminated.
This CL makes those changes to Dart.g. The changes have been in effect
for a while (8 months since last update to the spec), but the update
to Dart.g was somehow not performed at the time. This CL fixes that
omission.
Change-Id: Ifd2124583a124cdaaa7822f94f70e707ec33b425
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358460
Reviewed-by: William Hesse <whesse@google.com>
Commit-Queue: Erik Ernst <eernst@google.com>
llvm.sh must always use Linux newlines due to the #! line as a \r
character is considered part of the invoked program. This change fixes
that by simply forcing Unix newlines on all .sh files, like we do with
other file formats like C++ & Dart already.
Fixes: b/330293090
Change-Id: Iaf044da487261908f96c76d5c62385a033106a0b
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358480
Commit-Queue: Jonas Termansen <sortie@google.com>
Commit-Queue: William Hesse <whesse@google.com>
Auto-Submit: Jonas Termansen <sortie@google.com>
Reviewed-by: William Hesse <whesse@google.com>
Useful to focus on measuring performance of computing suggestions
only, without any overhead of resolution, protocol conversion, etc.
To be run as is, or with `--observe:xxxx` to see what to optimize.
You need to supply your own Flutter checkout.
Change-Id: Ie143b4ec9c24e05a0de2a14c1b8f0e1c20ef3a8a
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/358222
Reviewed-by: Brian Wilkerson <brianwilkerson@google.com>
Commit-Queue: Konstantin Shcheglov <scheglov@google.com>
Fixes https://github.com/dart-lang/sdk/issues/54937.
Tested: pkg/dartdev test for `dart devtools` command, and new `dtd_test.dart` in pkg/dds.
Change-Id: I530ba2fe4d5809082378b61c282ba7856974e21e
Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/354460
Commit-Queue: Kenzie Davisson <kenzieschmoll@google.com>
Reviewed-by: Ben Konyi <bkonyi@google.com>
Reviewed-by: Dan Chevalier <danchevalier@google.com>
