-
Notifications
You must be signed in to change notification settings - Fork 13.7k
Open
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsA-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.Area: Lints (warnings about flaws in source code) such as unused_mut.A-type-systemArea: Type systemArea: Type systemC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.E-needs-testCall for participation: An issue has been fixed and does not reproduce, but no test has been added.Call for participation: An issue has been fixed and does not reproduce, but no test has been added.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.T-langRelevant to the language teamRelevant to the language teamT-typesRelevant to the types team, which will review and decide on the PR/issue.Relevant to the types team, which will review and decide on the PR/issue.
Description
So this code produces a warning about the &*input
expression being unreachable:
enum Void { };
fn process(input: *const Void) {
let _input = &*input;
}
warning: unreachable expression
I can imagine this needs to "only" be a warning so someone can write some really janky macro code that very carefully ensures the expression isn't ever evaluated. Even if that's the case, I would appreciate that this get its own error-code, or just stronger language to indicate to the user that they are doing something Very Bad. In particular I believe evaluating this expr is Undefined Behaviour.
Metadata
Metadata
Assignees
Labels
A-diagnosticsArea: Messages for errors, warnings, and lintsArea: Messages for errors, warnings, and lintsA-lintsArea: Lints (warnings about flaws in source code) such as unused_mut.Area: Lints (warnings about flaws in source code) such as unused_mut.A-type-systemArea: Type systemArea: Type systemC-enhancementCategory: An issue proposing an enhancement or a PR with one.Category: An issue proposing an enhancement or a PR with one.E-needs-testCall for participation: An issue has been fixed and does not reproduce, but no test has been added.Call for participation: An issue has been fixed and does not reproduce, but no test has been added.T-compilerRelevant to the compiler team, which will review and decide on the PR/issue.Relevant to the compiler team, which will review and decide on the PR/issue.T-langRelevant to the language teamRelevant to the language teamT-typesRelevant to the types team, which will review and decide on the PR/issue.Relevant to the types team, which will review and decide on the PR/issue.
Activity
varkor commentedon Nov 24, 2018
I think what we want to be doing is distinguishing between unreachable code due to (control-flow) divergence and due to undefined behaviour in the diagnostics, whereas currently they're treated as the same thing.
hanna-kruppe commentedon Nov 24, 2018
&*input
should never actually dereference anything or create aVoid
value, it just converts the raw pointer to a reference. Is the warning based on the assumption that&!
is (validity-)uninhabited? AFAIK that is not decided yet.Gankra commentedon Nov 24, 2018
Ralf seemed to think this was materially different from transmuting to a reference, but I don't know why.
RalfJung commentedon Nov 24, 2018
Hm, good question actually. I've been thinking that we should assert validity of a value on a dereference (i.e., when evaluating a
*
, whether or not memory actually gets accessed). I thought that's what is happening here.But actually, miri only asserts validity when a value is copied at a certain type. That does not happen here. And your example code (after fixing syntax errors) actually has no "unreachable":
So there is no UB here, that miri sees anyway.
Things are very different if you use
!
instead:RalfJung commentedon Nov 24, 2018
I don't see a general principle here, but someone decided that a mere deref-without-actual-access on
!
is insta-UB.I think we should probably discuss this as part of rust-lang/unsafe-code-guidelines#8 in the UCG discussions. IMO, if we decide that references do not have to point to initialized data, then
&*
should not be UB. But if we decide that references have to point to initialized data, there is UB.estebank commentedon Sep 19, 2019
The current output for
is
17 remaining items