-
Notifications
You must be signed in to change notification settings - Fork 790
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
Deduplicate and sort error codes #15876
Conversation
Why the numbers are changed? The tooling, |
This is a good attempt. I think that changing codes of preview features is fine. But if there is an existing warning within the changeset, that might be a breaking change due to the way codes are used in compiler switches to turn warnings on/off and warnaserror. Was this checked? |
@auduchinok reason in title |
@T-Gro ah I didn't notice the invalid directive was a warning and not an error. I'll change the other one instead. |
I allso assume that a bunch of FSAC tests will be broken cc @baronfel @TheAngryByrd |
Sorry, I don't see any actual reason to change error numbers there. |
@auduchinok Every code should logically map to one error or warning. There has been precedence for making error codes unique: #12428 |
I'll add a script to ensure increasing error codes for good measure. |
I understand it, yes. I still can't see why 1503 is changed to 1003. There were no duplicates of it? |
@auduchinok That error is related to invoking the compiler via the command line and is written between codes 1000 and 1048. However, somehow, it uses 1503 which is far away from this range and may result in a potential collision in the future if someone decides to use the space between 1311 and 1999. A code between 1001 and 1047 would fit right in with the other messages about invoking the compiler via the command line. This is quite a niche error without search results and I don't think we would break anyone 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.
Looks good, check is great too.
cc @dotnet/fsharp-team-msft and @auduchinok let me know if that looks okay to you?
I really think we should never change error numbers based on a feeling that an error would be better with another number, but I agree that |
I don't thinks this should be a lot of new pain for merging anyway - whenever two new diagnostics are added at the same time, a merge conflict already happens anyway. => good for me, approved. Can be merged if all conversation are resolved. |
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 agree with Eugene in that I'd keep 1503 as it is.
But yeah it's not the end of the world on the other hand.
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 agree with Eugene in that I'd keep 1503 as it is.
But yeah it's not the end of the world on the other hand - as in, the world shouldn't explode from this.
No description provided.