Requesting review from:
Note that the changes to the `messages.yaml` files are large, but it should be fairly easy to have confidence in them, since the generated dart files are unchanged.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
Element p1: the name of the first declaring extensionFor messages to be shareable between analyzer and CFE we need to limit kinds of types that we can use - or make some pseudo types. Passing in types can be called `Type` (as I see you did below) which translates into the two `DartType` classes in the analyzer and CFE, respectively. For `Element` it is a bit harder - it could be `Element` in the analyzer and `NamedBuilder` in the CFE, but I think that is a bit of a reach. Maybe it would be better to use `String` instead in cases where we want a name.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
Element p1: the name of the first declaring extensionFor messages to be shareable between analyzer and CFE we need to limit kinds of types that we can use - or make some pseudo types. Passing in types can be called `Type` (as I see you did below) which translates into the two `DartType` classes in the analyzer and CFE, respectively. For `Element` it is a bit harder - it could be `Element` in the analyzer and `NamedBuilder` in the CFE, but I think that is a bit of a reach. Maybe it would be better to use `String` instead in cases where we want a name.
Agreed that we need to limit the kinds of types we can use. I'm not 100% sure what to do about Element yet.
The problem with using `String` instead of `Element` is that the analyzer's error formatting logic includes special handling of ambiguous elements. If we changed the type to `String`, then the ambiguous element handling would have to be inlined at all call sites, and there would be a lot of risk that we would sometimes get it wrong or forget to do it.
I'll do some investigation on the CFE side and make a recommendation for how to move toward a shared design that preserves the ambiguous element handling functionality.
| 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 |
The changes lgtm. I've sent an email to Parker (and included you on it). I hadn't thought about it before, but this might have implications for the way we generate documentation on `dart.dev`, so I wanted to get his input.
Object p0: the path of the file containing the errorI'm guessing that future CLs will improve both the type and the name of these parameters. If that's not the case please let me know.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Code-Review | +1 |
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
| Commit-Queue | +2 |
Object p0: the path of the file containing the errorI'm guessing that future CLs will improve both the type and the name of these parameters. If that's not the case please let me know.
Yes, my plan was to gradually improve these types and names as part of the process of converting the analyzer over to report the errors using the new (as yet unimplemented) literate API for reporting errors.
I'm also open to contributions if you (or anyone else) would like to take a stab at improving some of them in the meantime 😊
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |
[analyzer/linter] Use structured parameter format in messages.yaml.
This commit changes the format of `messages.yaml`. Message parameters
are now defined in a structured `parameters` section, replacing the
old free-form comments. This new format explicitly names and types
each parameter, which will allow for future improvements to static
error checking.
Also, the placeholder syntax is changed from `{N}` to `#NAME` to align
with the CFE, which will facilitate sharing error messages between the
analyzer and CFE in the future.
For now, the parameter names and types have been chosen fairly
arbitrarily; I plan to refine them in future CLs, working with small
sets of error messages at a time.
Additionally, the code generator now documents the parameters in a new
`Parameters:` section at the end of each error code's doc
comment. This change doesn't alter the generated files for now (to
give extra confidence that the change won't affect behavior). In a
follow-up, I plan to update the generated comments to include the
parameter names and types.
| Inspect html for hidden footers to help with email filtering. To unsubscribe visit settings. |