These make the init lists appear as if designated initialization was used.
Example:
ExpectedHint{"param: ", "arg"}
becomes
ExpectedHint{.Label="param: ", .RangeName="arg"}
Differential D116786
[clangd] Add designator inlay hints for initializer lists. sammccall on Jan 6 2022, 7:15 PM. Authored by
Details These make the init lists appear as if designated initialization was used. Example: ExpectedHint{"param: ", "arg"} becomes ExpectedHint{.Label="param: ", .RangeName="arg"}
Diff Detail
Event TimelineComment Actions (I know you're on vacation, this isn't urgent, just wanted to send it so I didn't lose it to git obscurity!)
Comment Actions Thanks, this is a pretty nice addition! My only piece of high-level feedback is probing if the array element designators ([0]=) are useful enough to be worth the space/noise. The rest is minor implementation comments.
Comment Actions a drive by concern around possible flakiness of the interaction. have you checked how does it look like when the user is still forming the initializer? it might be annoying if their cursor kept jumping around while they're editing the (possibly half-formed) initializer. Comment Actions Hmm, just tested and this is definitely a thing. Any ideas? :-(
Comment Actions
I've got a feeling that, this should also be annoying in the case of function calls (especially when there's only one overload)? Maybe we should just debounce the inlayhint requests (by saying contents modified to the clients)? Comment Actions This seems like the right track, but I'm not sure rejecting requests specifically is the right answer. Two reasons:
(As long as this is a custom protocol we can say what we want, but it won't be forever).
This isn't the drop-for-efficiency situation where the queue is full, this behavior is most annoying when the server is able to keep up with keystrokes. And the errors that cause this may not be trivially brief "i'm in the middle of typing a word" anyway. I'd suggest something slightly different: we compute inlay hints, heuristically merge with some previous state, and return the merged results.
(There's not much here that's specific to inlay hints vs other decorations tied to ranges - certainly we could/should do this for semantictokens too, and documentSymbols, ...) A variation on this idea is to compute these decorations frequently but "whenever we like" and always serve them from this cache, just patching them for changes in the source code. Comment Actions I was also thinking about a cache-based solution in which we can update results as we please, and as you noted the idea definitely generalizes to other requests as well, with possibly little nuances around the definition of "as we please", which makes things a lot more annoying as we can't have this as a single layer between all requests/responses but will require some feature specific customization. Comment Actions Agree. I guess then we ignore the issue for this patch? As you say that's affects other hints too, and a mitigation (hopefully) won't be specific to the kind of hint. Comment Actions Thanks, I'm happy to try the array designators and see how they work out in practice. The issue of hints appearing and disappearing as you type a function call is one I've noticed, but I've gotten used to it after a while. Improvements in this area would be nice but probably don't need to block the addition of new hints. Comment Actions
Yup. |
We could consider using the type name of the base (but I also get the impression that aggregate initialization with bases is uncommon enough to not worry about right now)