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!
1 Like
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. 
1 Like
I realize I gave a wrong example. This is what a "normal ICE" would looks like.
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.
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)
4 Likes
I think this is exactly the thing I was saying except the terminology 
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.
1 Like
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”.
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.
2 Likes
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.