-
Notifications
You must be signed in to change notification settings - Fork 347
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
README: update introduction #3583
Conversation
README.md
Outdated
All that said, be aware that Miri will **not catch all cases of undefined | ||
behavior** in your program, and cannot run all programs: | ||
All that said, be aware that Miri does **not catch every violation of the Rust | ||
specification** in your program, not least because there is no such specification. |
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.
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.
Hm, to me these are "just" bugs. I don't expect this list to generally be empty -- just like Rust has soundness bugs and still claims type safety.
I am not sure where we should put the threshold for prominently pointing out such bugs in our README.
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 have actually seen someone run into #845 and the conversation rapidly devolved into a bunch of very wrong speculation about how Rust works until found the conversation and linked the issue.
I agree that it is very hard to know where to draw the line, but I also think Miri is in a bit of a different position from rustc. People expect Miri to be the arbiter of when UB is executed, so when Miri is silent on a program that executes UB it's hard for people to know what to do. When rustc accepts your program then mangles it in codegen because of a soundness hole, you know something is afoot. But Miri never gives any indication that is is behaving buggily in this sense.
I also think it's a bit sketchy that an I-misses-ub has been open for (almost) 5 years. I know I looked over the implementation that would have to be done to fix it at one point, maybe I'll look again.
I like the mention of the issue label that you added, and I'm now happy with this PR overall. Advertising our errata list puts us a step ahead of some other parts of the Rust project :p
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.
When rustc accepts your program then mangles it in codegen because of a soundness hole, you know something is afoot.
rustc may also accept your program and happen to not exploit the UB. Then there's no indication that it behaves buggily.
I also think it's a bit sketchy that an I-misses-ub has been open for (almost) 5 years. I know I looked over the implementation that would have to be done to fix it at one point, maybe I'll look again.
Yeah, it's a tricky one. I was planning to work on it this summer.
All right, thanks! |
README: update introduction For some time now, we have (to my knowledge) been able to detect all the UB that rustc actually exploits. I think it's time to advertise that. We also haven't had the problem of "not every nightly has Miri" for a while. `@rust-lang/miri` what do you think?
☀️ Test successful - checks-actions |
For some time now, we have (to my knowledge) been able to detect all the UB that rustc actually exploits. I think it's time to advertise that.
We also haven't had the problem of "not every nightly has Miri" for a while.
@rust-lang/miri what do you think?