You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Refactor string interpolators and error message handling (#16384)
The idea is that we want to concentrate error handling logic in the
`Message` type instead of dispersing it over various
string interpolators.
- [x] Pass more messages instead of strings to `report` methods.
- [x] Make this easier by having string interpolators that produce
messages
- [x] Use messages instead of strings elsewhere
- [x] Move logic for limiting size of messages and filtering out
nonsensical errors into `Message`.
From the doc comment for `Message`:
## Tips for error message generation
- You can use the `em` interpolator for error messages. It's defined in
core.Decorators.
- You can also use a simple string argument for `error` or `warning`
(not for the other variants),
but the string should not be interpolated or composed of objects that
require a
Context for evaluation.
- When embedding interpolated substrings defined elsewhere in error
messages,
use `i` and make sure they are defined as def's instead of vals. That
way, the
possibly expensive interpolation will performed only in the case where
the message
is eventually printed. Note: At least during typer, it's common for
messages
to be discarded without being printed. Also, by making them defs, you
ensure that
they will be evaluated in the Message context, which makes formatting
safer
and more robust.
- For common messages, or messages that might require explanation,
prefer defining
a new `Message` in file `messages.scala` and use that instead. The
advantage is that these
messages have unique IDs that can be referenced elsewhere.
0 commit comments