Announcing Rust 2018 Preview 2!

[JeanMertz]

Thank you @johnthagen for the tip. I greatly appreciate the help. I am aware of the Jetbrains IDEs, but I’m not a fan of their visual clutter. I prefer vscode or sublime text (and accept the shortcomings that come with that).

My post wasn’t really a “help me find a solution” post, as I’m aware this is not the post (or the forum) to do so, but I wanted to give a quick insight into how a starting Rustacean is struggling with the current status of RLS, in case that helps in any way working towards a 1.0 release.

[earthengine]

The 2018 preview right now has relaxed the rule that we cannot call Box<dyn FnOnce>. However a CUP (Compiler UnexpectedUnconscious Panic, a much more serious problem than ICEs) was caused by this relax. The minimum reproducable is suprisingly simple, suggest that the shipping of this relax was not even tested with simplest use case.

Playground

fn foo(f: Box<dyn FnOnce()>) {
    f()
}
fn main() {}

(Rejected in 2015, CUP in 2018)

Tenichally speaking, the relax of the rule has nothing to do with the CUP. What it actually does is just triggering a bug that, when the MIR verifier have an inconsistent view of the program with the compiled code, it will not be able to handle some generated MIR, and crashes. In such a case, normally the compiler main thread shall catch the crash and report an error, but it didn’t because the crashed thread is in a “poisoned” state and so the main thread have no choice but panic.

EDIT I have created a post in rust users forum, talking about my observations on this bug. I appreciate any help for me to understand the code.

A pull request is now created.

[sfackler]

(Compiler Unexpected Panic, a much more serious problem than ICEs)

Uh, what? This is not a real distinction that I’m aware of. The majority of ICEs are caused by panics.

[earthengine]

The majority of ICEs are caused by panics.

The keyword here is “unexpected”, means the compiler have no idea about what the real problem is.

Other ICEs, on the other hand, usually will give you something that “Type mismatch when expected to match” or “Bad MIR” etc.

[sfackler]

You’re reading too much into the message the compiler’s panic hook printed. All ICEs are caused by the compiler encountering some state it doesn’t understand.

[earthengine]

To the end user, they are the same: you will see some messages that you are not suppose to understand;

But to the developers of the compiler, they are different. Normal ICEs like this one, will let you understand that the problem is in a struct called

OutputTypeParameterMismatch(Binder(<[closure@src/main.rs:13:17: 13:24] as std::ops::FnMut<(<Id<()> as Lt<'_>>::T,)>>), Binder(<[closure@src/main.rs:13:17: 13:24] as std::ops::FnMut<((),)>>), Sorts(ExpectedFound { expected: (), found: <Id<()> as Lt<'_>>::T }))` selecting `Binder(<[closure@src/main.rs:13:17: 13:24] as std::ops::FnMut<((),)>>)

and makes the diagnostic and fix much easier. The compiler developers can easily spot out: the compiler was consider () is matching <() as Lt<'_>>::T, but later it didn’t match them. This is inconsistent and so you can dig deeper into it and fix it.

But CUPs on the other hand, if gives you anything ever, it is something that is irrelevant to the program being compiling. This is harder to trace and debug.

[sfackler]

The compiler output for the “normal ICE” you linked literally contains the phrase “compiler unexpectedly panicked”.

[earthengine]

Yes… But I feel like I need to distinguish them anyways. Maybe “Compiler Unconscious Panic” would be a better term? Difference: normal panic is that you get killed but you can shout the name of the murderer, CUP is on the other hand the case when you get killed asleep…

EDIT OK, my investigate on this shows that “CUP” is a rare unfortunate situation simply because some code should be put in a scope to access the source code position but it was not. So after this has been fixed, there should be no more "CUP"s any more.

[huxi]

I had a bit of an issue with the documentation in the Edition Guide regarding path clarity.

The documentation gave me the impression that extern crate removal had already landed on nightly but the functionality isn’t there yet. It would be helpful if the status of the independent tracking issues could be integrated into the edition guide in some way. That way it would be easier to distinguish “not yet available” from an actual bug.

[uberjay]

extern crate is no longer needed, as long as you opt-in to the 2018 edition. Make sure you’re using the nightly compiler and that you’ve enabled the 2018 edition.

Add this to your Cargo.toml:

cargo-features = ["edition"]

[package]
edition = '2018'

That cargo-features line should go at the very top; and edition goes into the [package] section.

(From https://rust-lang-nursery.github.io/edition-guide/editions/transitioning-your-code-to-a-new-edition.html#switch-to-the-next-edition)

[huxi]

I added #![feature(rust_2018_preview, uniform_paths)] to my sources and executed cargo fix --allow-dirty --edition. That changed crate-internal use to the new use crate:: but kept all extern crate lines. I thought this was already the opt-in.

And the issue indicates (“disposition-merge”?) that its not yet included in Rust 2018 nightly… unless I miss(understand) something, which is entirely possible.

[uberjay]

I don’t think cargo fix removes the extern crate lines for you. (there’s this open issue https://github.com/rust-lang/rust/issues/52829) Also, you don’t need to enable uniform_paths, unless of course you’d like to try the uniform_paths feature – I’m pretty sure the path clarity options are orthogonal to the extern crate deprecation!

[huxi]

You are right, adding the suggested entries to the Cargo.toml (somewhat surprisingly) activated the extern crate stuff. cargo fix did indeed leave them in the code, causing compile errors. I +1ed the issue you linked.

Beside that I was able to build with edition 2018.

Example for the compile errors I got without manually removing the extern crate lines:

error: `chrono` import is ambiguous
   --> src/lib.rs:156:5
    |
153 | extern crate chrono;
    | -------------------- can refer to `self::chrono`
...
156 | use chrono::prelude::{DateTime, TimeZone, Utc};
    |     ^^^^^^ can refer to external crate `::chrono`
    |
    = help: write `::chrono` or `self::chrono` explicitly instead
    = note: relative `use` paths enabled by `#![feature(uniform_paths)]`

Mentioning them here since they are related to uniform_paths after all.

Oh, and rustfmt prevented me from trying the ::chrono suggestion because it simply removed the leading :: while I saved.

[earthengine]

The compiler output for the “normal ICE” you linked literally contains the phrase “compiler unexpectedly panicked”.

I realize I gave a wrong example. This is what a “normal ICE” would looks like.

Playground

trait Lt<'a> {
    type T;
}
struct Id<T>(T);
impl<'a,T> Lt<'a> for Id<T> {
    type T = T;
}

fn main() {
    let v = ();
    let f: fn(_) = |_:<Id<()> as Lt<'_>>::T| {};
    f(v)
    //~^ ICE: broken MIR in DefId
}

error message:

   Compiling playground v0.0.1 (file:///playground)
error: internal compiler error: broken MIR in DefId(0/0:8 ~ playground[b795]::main[0]) (_4 = _2): bad assignment (fn(()) = fn(<Id<()> as Lt<'_>>::T)): Sorts(ExpectedFound { expected: (), found: <Id<()> as Lt<'_>>::T })
  --> src/main.rs:12:5
   |
12 |     f(v)
   |     ^

error: aborting due to previous error

error: Could not compile `playground`.

To learn more, run the command again with --verbose.

[eddyb]

As a compiler developer, I can tell you there’s no strict distinction there, and we should probably remove the “unexpected panic” nonsense.

It’s just that some ICEs have slightly different sources than others so the output differs a bit, that’s all. They’re all ICEs and we want to melt them all.

(We do make a distinction though, and that’s between ICE-after-error and ICE-without-error - the former may be of lower priority because the compiler was going to stop anyway, whereas the latter breaks code that should succeed, so we might want to fix it sooner - this also holds somewhat for ICEs in stable features vs ICEs in nightly features, because only bugs in stable features are affected by release deadlines)

[earthengine]

(We do make a distinction though, and that’s between ICE-after-error and ICE-without-error

I think this is exactly the thing I was saying except the terminology

[eddyb]

What I meant there by “error” is a non-ICE intentional diagnostic, like a type mismatch.

None of your examples have a “normal error”, it’s just that some point to a code snippet and some don’t, which doesn’t matter that much.

[earthengine]

My last example do have a “normal error”: the NLL type checker think that (fn(()) = fn(<Id<()> as Lt<'_>>::T)) is not justified. This judgement is not consistent with the earlier compiler judgements, so we get ICE. But still, it is a “normal error” in the sense that if they were consistent, it will be a “normal error”.

[eddyb]

It’s not a normal error, it says right there “error: internal compiler error: broken MIR”. “broken MIR” is not an error for the user to read, it’s a compiler bug. Only different because it can point at your code, but this could’ve just been an assert_eq or something.

Also, this is very offtopic, we should take it elsewhere.

[aturon]

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.