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

constants are not constant due to ptr->int casts #18294

Closed
thestinger opened this issue Oct 24, 2014 · 3 comments · Fixed by #18315
Closed

constants are not constant due to ptr->int casts #18294

thestinger opened this issue Oct 24, 2014 · 3 comments · Fixed by #18315
Labels
A-type-system Area: Type system

Comments

@thestinger
Copy link
Contributor

fn main() {
    const X: u32 = 1;
    const Y: uint = &X as *const u32 as uint;
    println!("{}", Y);
}

Fixing this requires backwards incompatible changes to constant expressions. At a minimum, casts from pointers to integers need to be forbidden. It's possible that there are other issues.

@thestinger thestinger added I-wrong A-type-system Area: Type system labels Oct 24, 2014
@jdm
Copy link
Contributor

jdm commented Oct 24, 2014

Can you elaborate on the problem here?

@thestinger
Copy link
Contributor Author

@jdm: If it's not obvious from the code, compile and run it several times. The value of Y is determined at runtime so it's not a valid constant expression. The const type was supposed to be distinct from static by being a valid constant expression in every case but it is not.

@arielb1
Copy link
Contributor

arielb1 commented Oct 24, 2014

We really shouldn't be allowing pointer -> uint conversions in constexprs.

@thestinger thestinger changed the title constants are not constant constants are not constant due to ptr->int casts Oct 24, 2014
arielb1 added a commit to arielb1/rust that referenced this issue Oct 25, 2014
These cause issues, as addresses aren't fixed at compile-time.

Fixes rust-lang#18294
lnicola pushed a commit to lnicola/rust that referenced this issue Oct 22, 2024
Add wrap/unwrap return type in Option

I pretty much just copied over the code and tests for wrapping/unwrapping return types in `Result` and then did a bunch of find and replace changes.

I handled unwrapping statements returning `None` by just replacing `None` with the unit type, but I'm open to suggestions for more intuitive behavior here.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-type-system Area: Type system
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants