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

Coercion to an unspecified but easily inferrable raw pointer (`as *const _`) has regressed #23699

Closed
chris-morgan opened this Issue Mar 25, 2015 · 4 comments

Comments

Projects
None yet
6 participants
@chris-morgan
Copy link
Member

chris-morgan commented Mar 25, 2015

A couple of days ago it was all working fine, but in a fresh build (rustc 1.0.0-dev (593db005d 2015-03-25) (built 2015-03-25)) trouble is happening:

#![allow(dead_code)]

// Note that it’s got to be *const T; T compiles fine!
fn gimme_a_raw_pointer<T>(_: *const T) { }
fn gimme_a_raw_pointer_to_unit(_: *const ()) { }
fn gimme_a_raw_pointer_to_a_u8(_: *const u8) { }

fn main() {
    // This builds fine:
    //let pointer: *const _ = &();
    // But add an `as *const _` (the type ascription on `let pointer` is optional and meaningless):
    let pointer = &() as *const _;

    // Clearly `pointer` must be of type `*const ()`.

    // The real failure case was a “simple” `println!("{:?}", pointer)`.
    // I have extracted the essence of the failure here:
    gimme_a_raw_pointer(pointer);
    // Uncomment either of these two and it will suddenly figure out that that _ has got to be ().
    //gimme_a_raw_pointer_to_unit(pointer);
    //gimme_a_raw_pointer_to_a_u8(pointer);
}
<anon>:18:5: 18:24 error: unable to infer enough type information about `_`; type annotations required [E0282]
<anon>:18     gimme_a_raw_pointer(pointer);
              ^~~~~~~~~~~~~~~~~~~
error: aborting due to previous error
@Ms2ger

This comment has been minimized.

Copy link
Contributor

Ms2ger commented Mar 25, 2015

@Marwes

This comment has been minimized.

Copy link
Contributor

Marwes commented Mar 27, 2015

Smaller test case of what I believe to be the same bug.

fn test<T>(t: T) { }

fn main() {
    let t = test as fn (i32);
    t(0i32);
}

I don't have any knowledge of the inner workings of rustc but it seems that as doesn't unify the expression to the type at all. leading to the expr to still have an unknown type (fn (T) rather than fn (i32)).

@brson

This comment has been minimized.

Copy link
Contributor

brson commented Nov 17, 2016

Both examples seem to work. Just add them to the test suite.

@brson brson added the E-easy label Nov 17, 2016

@jneem

This comment has been minimized.

Copy link
Contributor

jneem commented Nov 17, 2016

I can do that

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Nov 22, 2016

Rollup merge of rust-lang#37851 - jneem:master, r=sanxiyn
Add a regression test for issue 23699.

This should close rust-lang#23699

GuillaumeGomez added a commit to GuillaumeGomez/rust that referenced this issue Nov 23, 2016

Rollup merge of rust-lang#37851 - jneem:master, r=sanxiyn
Add a regression test for issue 23699.

This should close rust-lang#23699

@bors bors closed this in #37851 Nov 23, 2016

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.