PTAL
https://dart-review.googlesource.com/c/sdk/+/488624/15..17 contains implementation of https://dart-https://github.com/dart-lang/sdk/issues/62944
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
The analysis_server, analyzer_plugin, linter, and API changes lgtm.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
visitNamedExpression (method: R? Function(NamedExpression))Something seems to be missing in this file; it only contains changes related to formal parameters and not for instance changes to arguments.
R? visitCollectionElement(CollectionElement node) => visitNode(node);
R? visitCombinator(Combinator node) => visitNode(node);Was this change intended?
/// arguments ::=
/// [NamedArgument] (',' [NamedArgument])*
/// | [Expression] (',' [Expression])* (',' [NamedArgument])*
@AnalyzerPublicApi(message: 'exported by lib/dart/ast/ast.dart')This seems to be the old grammar from before named-arguments-anywhere.
base mixin CollectionElementImpl on AstNodeImpl implements CollectionElement {This change doesn't seem to be related to any for mentioned changes (and like the cause of the change to the visitor).
/// A label on either a [LabeledStatement] or a deprecated named argument shape.Remove this?
var functionTypedSuffix = node.functionTypedSuffix;
if (functionTypedSuffix != null) {
var holder = ElementHolder(fragment);
_withElementHolder(holder, () {
_withElementWalker(
_elementWalker != null ? ElementWalker.forParameter(fragment) : null,
() {
node.metadata.accept(this);
node.documentationComment?.accept(this);
node.type?.accept(this);
functionTypedSuffix.typeParameters?.accept(this);
functionTypedSuffix.formalParameters.accept(this);
},
);
});
if (_elementWalker == null) {
fragment.typeParameters = holder.typeParameters;
fragment.formalParameters = holder.formalParameters;
}
} else {
node.metadata.accept(this);
node.documentationComment?.accept(this);
node.type?.accept(this);
}
_visitFormalParameterDefaultValue(node);Could we share this between the handling of the different formal parameters?
void visitShowCombinator(ShowCombinator node) {
var scope = nameScope.tryCast<LibraryFragmentScope>();
scope?.importsTrackingActive(false);
try {
super.visitShowCombinator(node);
} finally {
scope?.importsTrackingActive(true);
}
}
This change seem unrelated.
return _typeProvider.dynamicType;I guess this was triggered by the change to the `CollectionElementImpl` hierarchy. Should we handle `CollectionElementImpl` explicitly instead?
return _InferredCollectionElementTypeInformation();Ditto.
void visitNamedArgument(NamedArgument node) {
_invalidAccessVerifier.verifyNamedArgument(node);
super.visitNamedArgument(node);
}
Is this new functionality? (I don't see any previous code for `NamedExpression`)
AstNode errorNode,
Expression expression,Not for this CL: We should use named parameters for these. Call-sites are confusing.
/// This is set to `true` iff the visitor is currently within a function typed
/// formal parameter.
/// A flag indicating whether the visitor is currently within code in the SDK.Remove?
case ExtensionOverride(argumentList: ArgumentListImpl(arguments: [_])):
case _:
ExpressionImpl shortingTarget = switch (target) {
ExtensionOverride(:var argumentList) =>
argumentList.arguments[0].argumentExpression as ExpressionImpl,
_ => target,
};
flow.storeExpressionInfo(I think this can be written as
case ExtensionOverride(argumentList:
ArgumentListImpl(arguments: [
ArgumentImpl(argumentExpression: var expression)
]))):
case var expression:
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
visitNamedExpression (method: R? Function(NamedExpression))Something seems to be missing in this file; it only contains changes related to formal parameters and not for instance changes to arguments.
Indeed, because it was impossible to run bots at all, I forgot to regenerate.
Fixed.
R? visitCollectionElement(CollectionElement node) => visitNode(node);
R? visitCombinator(Combinator node) => visitNode(node);Konstantin ShcheglovWas this change intended?
Yes, see https://github.com/dart-lang/sdk/issues/62944 "5. Syntactic Types and Contextual Roles"
/// arguments ::=
/// [NamedArgument] (',' [NamedArgument])*
/// | [Expression] (',' [Expression])* (',' [NamedArgument])*
@AnalyzerPublicApi(message: 'exported by lib/dart/ast/ast.dart')This seems to be the old grammar from before named-arguments-anywhere.
Done
base mixin CollectionElementImpl on AstNodeImpl implements CollectionElement {This change doesn't seem to be related to any for mentioned changes (and like the cause of the change to the visitor).
See https://github.com/dart-lang/sdk/issues/62944 "5. Syntactic Types and Contextual Roles". It is actually intentional.
/// A label on either a [LabeledStatement] or a deprecated named argument shape.Konstantin ShcheglovRemove this?
Done
var functionTypedSuffix = node.functionTypedSuffix;
if (functionTypedSuffix != null) {
var holder = ElementHolder(fragment);
_withElementHolder(holder, () {
_withElementWalker(
_elementWalker != null ? ElementWalker.forParameter(fragment) : null,
() {
node.metadata.accept(this);
node.documentationComment?.accept(this);
node.type?.accept(this);
functionTypedSuffix.typeParameters?.accept(this);
functionTypedSuffix.formalParameters.accept(this);
},
);
});
if (_elementWalker == null) {
fragment.typeParameters = holder.typeParameters;
fragment.formalParameters = holder.formalParameters;
}
} else {
node.metadata.accept(this);
node.documentationComment?.accept(this);
node.type?.accept(this);
}
_visitFormalParameterDefaultValue(node);Could we share this between the handling of the different formal parameters?
Hm...
I'm almost sure that you made this same comment the previous review round.
And I remember doing it too.
But apparently it did not go into the result.
Sorry about this. Done now.
void visitShowCombinator(ShowCombinator node) {
var scope = nameScope.tryCast<LibraryFragmentScope>();
scope?.importsTrackingActive(false);
try {
super.visitShowCombinator(node);
} finally {
scope?.importsTrackingActive(true);
}
}
Konstantin ShcheglovThis change seem unrelated.
It just sorted after `visitRegularFormalParameter` now, see left panel line 812.
I guess this was triggered by the change to the `CollectionElementImpl` hierarchy. Should we handle `CollectionElementImpl` explicitly instead?
Yes, the problem is that `CollectionElementImpl` is not a sealed class anymore, it is not a class at all:
```
base mixin CollectionElementImpl on AstNodeImpl implements CollectionElement {}
```
So, we cannot do exhaustive switch on it.
I will make it more explicit by adding default-throw.
return _InferredCollectionElementTypeInformation();Konstantin ShcheglovDitto.
Done
void visitNamedArgument(NamedArgument node) {
_invalidAccessVerifier.verifyNamedArgument(node);
super.visitNamedArgument(node);
}
Is this new functionality? (I don't see any previous code for `NamedExpression`)
No, this is not a new functionality. Previously we used `NamedExpression` that had `Label`, which was a wrapper around `SimpleIdentifier`. So, we would check through it. This is a wrong model, but it duck-fitted into the check. As we fix the model, we make checks explicit.
Not for this CL: We should use named parameters for these. Call-sites are confusing.
Acknowledged
/// This is set to `true` iff the visitor is currently within a function typed
/// formal parameter.
/// A flag indicating whether the visitor is currently within code in the SDK.Konstantin ShcheglovRemove?
Done
case ExtensionOverride(argumentList: ArgumentListImpl(arguments: [_])):
case _:
ExpressionImpl shortingTarget = switch (target) {
ExtensionOverride(:var argumentList) =>
argumentList.arguments[0].argumentExpression as ExpressionImpl,
_ => target,
};
flow.storeExpressionInfo(I think this can be written as
case ExtensionOverride(argumentList:
ArgumentListImpl(arguments: [
ArgumentImpl(argumentExpression: var expression)
]))):
case var expression:
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
I can't be sure that I've verified all of the changes. There are just too many of them for me to have confidence that I didn't miss something. But I've done my best to do more than just a spot check, and we'll have to hope that the tests are adequate.
void visitNamedArgument(NamedArgument node) {It seems odd that this isn't replacing some existing code. Is this new behavior?
node.argumentExpression.accept(this);It seems like it would be both more future proof and more consistent for this to just invoke `super.visitNamedArgument(node);`.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
void visitNamedArgument(NamedArgument node) {It seems odd that this isn't replacing some existing code. Is this new behavior?
Previously we were doing this in `visitSimpleIdentifier`
node.argumentExpression.accept(this);It seems like it would be both more future proof and more consistent for this to just invoke `super.visitNamedArgument(node);`.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
Changes in tests/language lgtm.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +2 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +2 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
42 is the latest approved patch-set.
No files were changed between the latest approved patch-set and the submitted one.
Breaking changes for analyzer 13.0.0
https://github.com/dart-lang/sdk/issues/62799
https://github.com/dart-lang/sdk/issues/62944
https://github.com/dart-lang/sdk/issues/63002
https://github.com/dart-lang/sdk/issues/62970
Looks mostly green in google3: https://fusion2.corp.google.com/presubmit/901021300/OCL:901021300:BASE:901308428:1776439417713:37cd1695
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
now the roll CL requires 6 extra owner approvals, as the google3 hotfix is not trivial and Morgan refuses to GA it. Did it have to be so breaking?
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
The breaks the Dart->Flutter roll: https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8683906748892186497/+/u/test:_Host_Tests_for_host_debug/stdout
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
The breaks the Dart->Flutter roll: https://logs.chromium.org/logs/flutter/buildbucket/cr-buildbucket/8683906748892186497/+/u/test:_Host_Tests_for_host_debug/stdout
Sorry about that.
See https://github.com/flutter/flutter/pull/185360
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |