Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Suggest
_
and..
if a pattern has too few fields #80017Suggest
_
and..
if a pattern has too few fields #80017Changes from all commits
16692ab
5fe61a7
f3d9df5
a5e8e6e
fe82cc3
9959d6d
1bce775
d7307a7
e8c8793
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the
DUMMY_SP
for and this branch for? I never seen this before.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is to prevent a compiler crash if
pat_span == DUMMY_SP
since we then subtract1
frompat_span
andDUMMY_SP
is basically equal to 0.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If
pat_span
isDUMMY_SP
then you shouldn't be giving suggestions at all.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What happens if the error rendering system receives a diagnostic that has
DUMMY_SP
? Will it just ignore it?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The error renderer will ignore
DUMMY_SP
s and not show labels associated to it, while still showing messages, but they do have the potential to break suggestions and certainly break everything when synthesizing a new span from them.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be good to add a comment for potential improvements here.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be better to show an example here for the comment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These two cases should also be suggesting
..
as an alternative, no?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well, if someone is already explicitly listing out wildcards, should we suggest that they use
..
? On the other hand, someone may not know that..
is an option and would rather that over listing out wildcards manually. So I think overall I agree with you that we should be giving it as an alternative :)I'll change it, but for other things we can always adjust the behavior later; I'm hoping to have this PR finished soon.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds reasonable, I don't foresee any big changes. I think that the code itself looks good but want to nail down the exact behavior we want.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So is the behavior you're suggesting that we also suggest
S(..)
if it's currently of the formS(_, _, _)
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, I think that if it is currently
S(_, _)
and we suggestS(_, _, _)
we should also suggestS(..)
. Having said that, if you find that it will be too much work, only create a follow-up ticket and r=me.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that we'll need to special case when there's only one field missing (and all the other preceding fields aren't
_
) and _only suggest_
. To clarify, I think that in this case we should only provide the first suggestion, not the..
one. That being said, it is something I can look at myself if you're itching to merge asap.It also feels like we could deal with language for a single field. My ideal output for this case would be:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I actually think we should suggest
..
in this case. It's very possible that someone didn't list any fields because they want to match on the outer structure, and so they just want to ignore all of them. We should definitely suggest..
in that case.And also, as you said, I would like to get this merged soon. I appreciate the desire to make diagnostics as good as possible - I share that desire - but I feel that further changes would have diminishing returns and increase the risk of introducing bugs. Also, this change has taken way longer than I anticipated and I would like to spend my time on some other things :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why don't we suggest
Color::Rgb(_, _, ..)
as well? I think the above is enough but we could show the other possible options.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I consider
Color::Rgb(_, _, ..)
is bad style. :)Edit: let me clarify :)
Rgb(_, _, _)
is useful because you're saying "I care ifRgb
changes and adds fields", whileRgb(..)
is saying "I don't care about the values, I just care about the tagged variant".Rgb(_, _, ..)
seems to be saying "I only care to change this pattern if the variant has less than 3 fields", which seems very special cased to me.