Skip to content
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

ctfe validation on unaligned references does not mention expected / provided alignment #58617

Closed
gnzlbg opened this issue Feb 21, 2019 · 9 comments
Labels
A-const-eval Area: Constant evaluation (MIR interpretation) A-diagnostics Area: Messages for errors, warnings, and lints E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.

Comments

@gnzlbg
Copy link
Contributor

gnzlbg commented Feb 21, 2019

This code (playground):

fn main() {
    unsafe {
        use std::mem::transmute;
        let a = 0_u8;
        let b = &a as *const u8 as *const u64;
        //let _c: &u64 = transmute(b);
        let _d = *b;
    }
}

errors under miri with

tried to access memory with alignment 1, but alignment 8 is required

This snippet, however (playground):

fn main() {
    unsafe {
        use std::mem::transmute;
        let a = 0_u8;
        let b = &a as *const u8 as *const u64;
        let _c: &u64 = transmute(b);
        //let _d = *b;
    }
}

errors with

type validation failed: encountered unaligned reference

It would be great if this error about the validity of references would also state that "alignment 1, but alignment 8 is required" or similar.

cc @oli-obk @RalfJung

@oli-obk oli-obk added A-diagnostics Area: Messages for errors, warnings, and lints A-const-eval Area: Constant evaluation (MIR interpretation) E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion. labels Feb 21, 2019
@oli-obk
Copy link
Contributor

oli-obk commented Feb 21, 2019

I think all we need is

EvalErrorKind::AlignmentCheckFailed { .. } =>
return validation_failure!("unaligned reference", self.path),
to actually use the fields of the AlignmentCheckFailed and add their information to the validation failure string.

@oli-obk oli-obk added the E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. label Feb 21, 2019
@pmccarter
Copy link
Contributor

I'd like to do it.

@oli-obk
Copy link
Contributor

oli-obk commented Feb 21, 2019

It's all your's, let me know if you have any questions

@pmccarter
Copy link
Contributor

Hmm both of these snippets seem to compile in the playground (when unused use removed).

@gnzlbg
Copy link
Contributor Author

gnzlbg commented Feb 21, 2019

Yes the examples compile fine. The issue is triggered by running them under miri.

@oli-obk
Copy link
Contributor

oli-obk commented Feb 21, 2019

You can probably repro the same thing in rustc with const eval by making the final value be such an invalid reference

@oli-obk
Copy link
Contributor

oli-obk commented Feb 21, 2019

Jup, here's a repro (that you can use as a regression test, too):

#![feature(const_transmute)]
const FOO: &u64 = unsafe {
    use std::mem::transmute;
    let a = &0_u8;
    let b = a as *const u8 as *const u64;
    transmute(b)
};

@hellow554
Copy link
Contributor

Note, that clippy does emit an error:

error: casting from *const u8 to a more-strictly-aligned pointer (*const u64)

@gnzlbg
Copy link
Contributor Author

gnzlbg commented Feb 22, 2019

@hellow554 thanks, i've reported the issue there tiL rust-lang/rust-clippy#3797

Centril added a commit to Centril/rust that referenced this issue Feb 23, 2019
Add expected/provided byte alignments to validation error message

Fixes rust-lang#58617
Centril added a commit to Centril/rust that referenced this issue Feb 23, 2019
Add expected/provided byte alignments to validation error message

Fixes rust-lang#58617
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-const-eval Area: Constant evaluation (MIR interpretation) A-diagnostics Area: Messages for errors, warnings, and lints E-easy Call for participation: Easy difficulty. Experience needed to fix: Not much. Good first issue. E-mentor Call for participation: This issue has a mentor. Use #t-compiler/help on Zulip for discussion.
Projects
None yet
Development

No branches or pull requests

4 participants