-
Notifications
You must be signed in to change notification settings - Fork 4.7k
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
Don't crash the trim analyzer if it finds unrecognized nodes in the input #88836
Don't crash the trim analyzer if it finds unrecognized nodes in the input #88836
Conversation
…nput New versions of the compiler will introduce new nodes and values. The analyzer can never be 100% in sycn with the compiler, so it needs to be able to gracefully handle nodes it doesn't know anything about. Change the several throws to just Debug.Fail. For end-users if we hit unrecognized node, we will effectively ignore that part of the code. So not 100% precise, but the analyzer will never be 100% regardles. This is in response to dotnet#88684, but we can't add tests for it yet because the necessary compiler changes are in Preview 6, the repo is still on Preview 5.
Tagging subscribers to this area: @agocke, @sbomer, @vitek-karas Issue DetailsNew versions of the compiler will introduce new nodes and values. The analyzer can never be 100% in sync with the compiler, so it needs to be able to gracefully handle nodes it doesn't know anything about. Change the several throws to just This is in response to #88684, but we can't add tests for it yet because the necessary compiler changes are in Preview 6, the repo is still on Preview 5.
|
Tagging subscribers to 'linkable-framework': @eerhardt, @vitek-karas, @LakshanF, @sbomer, @joperezr, @marek-safar Issue DetailsNew versions of the compiler will introduce new nodes and values. The analyzer can never be 100% in sync with the compiler, so it needs to be able to gracefully handle nodes it doesn't know anything about. Change the several throws to just This is in response to #88684, but we can't add tests for it yet because the necessary compiler changes are in Preview 6, the repo is still on Preview 5.
|
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 are your thoughts on making this a warning instead? It would be nice to leave some feedback channel for the unimplemented cases.
I'm on the edge on this one:
Currently I'm slightly leaning towards silence. Basically the thinking is:
The argument against the warning is: If this happens to you (maybe because of a nuget dependency for example), there's nothing you can do other than file the issue (which most people won't bother with anyway). And there's no "Fixing it" either, you have to figure out the NoWarn and suppress it. But that's likely going to stay in your codebase forever, and so the next time this happens, you won't know and won't tell us anyway. |
I agree that for large compiler features we would probably be able to anticipate this. I also see the potential problem you point out with NoWarn, especially since a suppression would prevent future warnings about different unimplemented node types. I still think we would get good feedback from a warning; the warning could say "please file an issue". For smaller cases like this, I don't think we would have found out about this hole until much later without the feedback channel. Another idea is to run the debug version of the analyzer on runtime bits (not sure if the performance would be acceptable - maybe we would do it in certain ci legs only)? @agocke in case you have other ideas. |
Warnings are errors for customers. Can't do that.
|
Actually I think it would be valuable to have a CI leg which runs as many analyzers/sourcegenerators as we can in Debug mode. Ideally all the analyzers which are built by the runtime repo (but I don't know how the codeflow is setup). I filed #88901 to track that. |
There's also something I remember called a "non-fatal Watson" which is supposed to send some sort of Watson failure, without crashing or throwing. I can go searching for what that is. |
New versions of the compiler will introduce new nodes and values. The analyzer can never be 100% in sync with the compiler, so it needs to be able to gracefully handle nodes it doesn't know anything about.
Change the several throws to just
Debug.Fail
. For end-users if we hit unrecognized node, we will effectively ignore that part of the code. So not 100% precise, but the analyzer will never be 100% regardless.This is in response to #88684, but we can't add tests for it yet because the necessary compiler changes are in Preview 6, the repo is still on Preview 5.