-
Notifications
You must be signed in to change notification settings - Fork 13.2k
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
rustc silently ignores a class of errors in flexible target json files #24384
Comments
This isn't strictly diagnostics, but close enough. |
Yeah, this has annoyed me recently too, when I originally did this I decided not to validate the precense of extra fields for compatability with future fields in other rustc versions (As otherwise it's not possible to have a new target spec work on an old rustc at all). I'm pretty sure that we should NOTABUG that, but do stricter validation for types. |
Triage: I don't believe that anything has changed here, but I can't check exactly right now. |
This seems like we'd want to do stricter validation of types. I'm somewhat surprised we don't today, but it's possible this could be fixed by moving to Serde for deserialization (even if just into serde_json::Value) since it does far more strict validations. |
So, I thought that there was a PR to fix this, but I cannot find it. Regardless, when trying to build a project using the above target spec:
fixing some of it up:
so, it does seem like this has been fixed. Closing! |
Currently
rustc
will allow for extra fields to be added to flexible target json without notifying the user, even with--verbose
. For example, the following is accepted:dynamic_linking
has a underscore separator instead of a hyphen.morestack
is of type bool, but a string was providedpre-link-args
takes an array of strings, but a string was providedThe last three entries have errors that could be easy to miss. This is worrying, because for all the optional fields, simple errors such as misspellings will cause those fields to be discarded and the default values to be used instead. To the programmer it could seem as if the configuration is in place when in reality the compiler simply went with the default value.
I had one of these happen to me earlier and I almost missed it completely. I think that this should at the very least trigger a warning.
The text was updated successfully, but these errors were encountered: