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

Clarify our story with as and type placeholders. #12894

Closed
Kimundi opened this issue Mar 14, 2014 · 8 comments
Closed

Clarify our story with as and type placeholders. #12894

Kimundi opened this issue Mar 14, 2014 · 8 comments
Labels
A-type-system Area: Type system

Comments

@Kimundi
Copy link
Member

Kimundi commented Mar 14, 2014

Right now the compiler accepts partial type hints for casts with as like this:

let x = &5 as *_;

However, it fails with a fully unrestricted type on the right hand side with a unhelpful error message:

.../type_hole_1.rs:35:18: 35:22 error: the type of this value must be known in this context
.../type_hole_1.rs:35     let a: int = 1u32 as _;
                                       ^~~~

To quote @nikomatsakis:
"The reason that the type check doesn't work is because we check immediately that the as conversion is legal. We could just say that the type of <expr> as T is T and then go back and check later that the type conversion is legal once types are known. I kind of like that."

There are three possible ways to resolve this:

  • Explicitly allow type placeholders in as, which means fixing the as _ case.
  • Explicitly forbid type placeholders in as, which means preventing partial type hints in as in general.
  • Only forbid as _, while allowing partial type hints otherwise. This means catching the error case and emitting a useful error message.
@reem
Copy link
Contributor

reem commented Dec 15, 2014

Triage: this is still a problem, and is now worse because let a: int = 5u as _; now ICEs rather than just erroring.

EDIT: I originally misread the issue

@steveklabnik
Copy link
Member

 let x = &5 as *const _;

now works just fine.

@Kimundi
Copy link
Member Author

Kimundi commented Nov 7, 2015

as X<_> always worked just fine, its the as _ case that is the problem. :)

@Kimundi Kimundi reopened this Nov 7, 2015
@steveklabnik
Copy link
Member

Ugh, sorry :(

@nikomatsakis
Copy link
Contributor

Interestingly, the fact that x as *const _ works is kind of an accident. That is, the code is not "intending" for it to work -- it is setup to have as not influence type inference at all -- but due to a bug it does, and I figure it's too entrenched to break. (It's dang convenient, that's for sure!)

@arielb1
Copy link
Contributor

arielb1 commented Nov 14, 2015

@nikomatsakis

Not really. The casted-to type (*const _) is the cast expression's return type, which is later unified with the expression's expected type. Actual cast checking, which takes place fairly late, sees the cast as x as *const u8. The reason this doesn't work with as *const _ is because of a dubious type_is_known_to_be_sized check at https://github.com/rust-lang/rust/blob/master/src/librustc_typeck/check/mod.rs#L3495.

I feel like we should move it to cast checking. Should I write a PR?

@nikomatsakis
Copy link
Contributor

@arielb1

Not really. The casted-to type (*const _) is the cast expression's return type, which is later unified with the expression's expected type.

This is how it is supposed to work, yes, but I think there are cases where the value is not fully inferred before casts are processed. At some point I was introducing more hard errors before cast checking for unresolved variables, and I got errors for this reason, and had to modify the code some. I'd have to go back digging to be more precise though.

arielb1 pushed a commit to arielb1/rust that referenced this issue Nov 25, 2015
the problem is that now "type_is_known_to_be_sized" now returns
false when called on a type with ty_err inside - this prevents
spurious errors (we may want to move the check to check::cast
anyway - see rust-lang#12894).
nikomatsakis pushed a commit to nikomatsakis/rust that referenced this issue Jan 9, 2016
the problem is that now "type_is_known_to_be_sized" now returns
false when called on a type with ty_err inside - this prevents
spurious errors (we may want to move the check to check::cast
anyway - see rust-lang#12894).
nikomatsakis pushed a commit to nikomatsakis/rust that referenced this issue Jan 12, 2016
the problem is that now "type_is_known_to_be_sized" now returns
false when called on a type with ty_err inside - this prevents
spurious errors (we may want to move the check to check::cast
anyway - see rust-lang#12894).
@Mark-Simulacrum
Copy link
Member

The following now successfully compiles, so we've effectively clarified the story, since as far as I know we cannot change this in a backwards compatible way. Closing since there appears to be nothing left to do in this issue.

fn main() {
    let a: i32 = 1u32 as _;
}

bors added a commit to rust-lang-ci/rust that referenced this issue Sep 24, 2024
…lyxyas

[`manual_div_ceil`]: init

Suggest using `div_ceil()` instead of manual implementation for basic cases.

Partially fixes rust-lang#12894

changelog: new lint: [`manual_div_ceil`]
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

No branches or pull requests

7 participants