Paul Berry
ff5962306a
This is part of a series of CLs that will standardize CFE error reporting to always use `codeFoo.withArguments(...)` when reporting errors that take arguments and `codeFoo` when reporting errors that don't take arguments, rather than `templateFoo.withArguments(...)` when reporting errors that take arguments and `messageFoo` when reporting errors that don't take arguments. This change will have two advantages: - It will lend greater consistency to the CFE codebase, by allowing the same `code...` objects to be used both to name error codes (e.g., in test expectations) and to report errors. This will allow everything associated with a certain error code to be found using a single invocation of "Find References" in the editor, rather than having to search separately for uses of the code and the message or template. - It should hopefully make the experience of writing code that reports errors more pleasant, since it will no longer be necessary to look up an error to see whether it takes arguments before using it; instead, the developer will be able to type the name of the message `code...` declaration, and then use autocompletion to see whether `.withArguments(...)` is required. In this CL, the code generator for error messages is changed so that both `template...` and `code...` declarations have the static type `Template` (and, indeed, refer to the same constant object). Previously, `code...` declarations had the static type `Code`, and referred to a constant object with runtime type `Code`. This will allow uses of `template...` to be replaced with `code...`. In follow-up CLs, the uses of `template...` will be changed to `code...`, and the `template...` declarations will be removed. Since the `toString` methods on `Template` and `Code` differ, I had to make some changes to ID tests and parser tests, both of which depend on the behavior of `toString`: - For ID tests, I was able to preserve the existing test expectations by modifying the `errorsToText` function (in `pkg/front_end/lib/src/testing/id_testing_utils.dart`). - For parser tests, I wasn't able to find an easy way to preserve the existing test expectations, so I updated the expectations to match the new behavior. Change-Id: I8a461d451b06dd2f88b3e59f0cb2153711b09461 Reviewed-on: https://dart-review.googlesource.com/c/sdk/+/442731 Commit-Queue: Paul Berry <paulberry@google.com> Reviewed-by: Johnni Winther <johnniwinther@google.com>
41 lines
1.5 KiB
Plaintext
41 lines
1.5 KiB
Plaintext
Problems reported:
|
|
|
|
parser/patterns/declaredVariable_inPatternAssignment_usingVar:2:11: Variable 'd' can't be declared in a pattern assignment.
|
|
[a, var d] = y;
|
|
^
|
|
|
|
beginCompilationUnit(void)
|
|
beginMetadataStar(void)
|
|
endMetadataStar(0)
|
|
beginTopLevelMember(void)
|
|
beginTopLevelMethod(, null, null)
|
|
handleVoidKeyword(void)
|
|
handleIdentifier(f, topLevelFunctionDeclaration)
|
|
handleNoTypeVariables(()
|
|
beginFormalParameters((, MemberKind.TopLevelMethod)
|
|
endFormalParameters(0, (, ), MemberKind.TopLevelMethod)
|
|
handleAsyncModifier(null, null)
|
|
beginBlockFunctionBody({)
|
|
beginPattern({)
|
|
handleNoTypeArguments([)
|
|
beginPattern([)
|
|
handleAssignedVariablePattern(a)
|
|
endPattern(a)
|
|
beginPattern(,)
|
|
handleNoType(var)
|
|
handleRecoverableError(Message[Template(PatternAssignmentDeclaresVariable), Variable 'd' can't be declared in a pattern assignment., Try using a preexisting variable or changing the assignment to a pattern variable declaration., {name: d}], d, d)
|
|
handleDeclaredVariablePattern(var, d, true)
|
|
endPattern(d)
|
|
handleListPattern(2, [, ])
|
|
endPattern(])
|
|
handleIdentifier(y, expression)
|
|
handleNoTypeArguments(;)
|
|
handleNoArguments(;)
|
|
handleSend(y, y)
|
|
handlePatternAssignment(=)
|
|
handleExpressionStatement([, ;)
|
|
endBlockFunctionBody(1, {, })
|
|
endTopLevelMethod(void, null, })
|
|
endTopLevelDeclaration(})
|
|
endCompilationUnit(1, )
|