commit ff5962306a2f3e7a7e5513a3a2afd5b578ef2f8e
author Paul Berry <paulberry@google.com> Wed Aug 06 06:37:31 2025 -0700
committer Commit Queue <dart-scoped@luci-project-accounts.iam.gserviceaccount.com> Wed Aug 06 06:37:31 2025 -0700
tree 8175f31b1d4798a7b2f21b28cab73a8b487d29c8
parent e32c2ac7967334c9451a16fde08cb2e6c10d6d35

[front end] Make `code...` objects usable as error templates.

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>