Loosely inspired by SR-11024, lately I've been thinking about ways we could improve diagnostic formatting by making use of the structured information provided by diagnostic arguments. For example, while the above bug has been fixed to disambiguate types with ambiguous spellings which appear together in a single diagnostic, a number of similar bugs like SR-11166 still exist.
There are a few steps I think we could take to resolve this and similar bugs, and maybe use to enable further improvements down the road. Roughly, they're:
- Allow defining fix-its which accept typed diagnostic arguments (similar to errors/warnings/notes today)
- Format a fix-it's arguments alongside those of its parent diagnostic to perform type disambiguation/other operations
- (Maybe) Establish a tighter relationship between notes and their parent error or warning to perform additional disambiguation
Before I explore this further I thought it would be a good idea to solicit some feedback, especially regarding the first point. I did some quick prototyping, and so far have found that:
- Hooking fix-it arguments up to the existing diagnostics formatting pipeline shouldn't be too difficult
- Structured fix-its aren't a good fit for all fixits (especially deletions and simple inserts). They would need to be an optional alternative to the current
.fixIt...methods - Using format strings and arguments does seem like a good opportunity to refactor some of the more complicated fix-its
I'd be interested to hear everyone's thoughts on this!