Question:
<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Given that it doesn't reproduce on godbolt I guess this is apple specific?.
I can reproduce it in playground: godbolt builds Rust code as by default.
Assigning as and removing .
There is no need for containing . Renaming to anything and make it is suffice. The error traces back to 1.0 Rust release:
here is the unwrap to blame.
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.

<ins> #![feature(type_alias_impl_trait)] #![feature(impl_trait_in_bindings)] #![allow(incomplete_features)] type FooArg<'a> = &'a dyn ToString; type FooRet = impl std::fmt::Debug; type FooItem = Box<dyn Fn(FooArg) -> FooRet>; type Foo = impl Iterator<Item = FooItem>; //~ ERROR: type mismatch #[repr(C)] struct Bar(u8); impl Iterator for Bar { type Item = FooItem; fn next(&mut self) -> Option<Self::Item> { Some(Box::new(quux)) } } fn quux(st: FooArg) -> FooRet { Some(st.to_string()) } fn ham() -> Foo { Bar(1) } fn oof() -> impl std::fmt::Debug { let mut bar = ham(); let func = bar.next().unwrap(); return func(&"oof"); } fn main() { let _ = oof(); } </ins>


Question:
<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Given that it doesn't reproduce on godbolt I guess this is apple specific?.
I can reproduce it in playground: godbolt builds Rust code as by default.
Assigning as and removing .
There is no need for containing . Renaming to anything and make it is suffice. The error traces back to 1.0 Rust release:
here is the unwrap to blame.
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.

<ins> error[E0271]: type mismatch resolving `<Bar as Iterator>::Item == Box<(dyn for<'r> Fn(&'r (dyn ToString + 'r)) -> Option<String> + 'static)>` --> $DIR/issue-70877.rs:9:12 | LL | type FooRet = impl std::fmt::Debug; |               -------------------- the expected opaque type ... LL | type Foo = impl Iterator<Item = FooItem>; |            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected opaque type, found enum `Option` | = note: expected struct `Box<(dyn for<'r> Fn(&'r (dyn ToString + 'r)) -> impl Debug + 'static)>` found struct `Box<(dyn for<'r> Fn(&'r (dyn ToString + 'r)) -> Option<String> + 'static)>` error: aborting due to previous error For more information about this error, try `rustc --explain E0271`. </ins>


Question:
<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Given that it doesn't reproduce on godbolt I guess this is apple specific?.
I can reproduce it in playground: godbolt builds Rust code as by default.
Assigning as and removing .
There is no need for containing . Renaming to anything and make it is suffice. The error traces back to 1.0 Rust release:
here is the unwrap to blame.
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.

<ins> // check-pass // Regression test of #70944, should compile fine. use std::ops::Index; pub struct KeyA; pub struct KeyB; pub struct KeyC; pub trait Foo: Index<KeyA> + Index<KeyB> + Index<KeyC> {} pub trait FooBuilder { type Inner: Foo; fn inner(&self) -> &Self::Inner; } pub fn do_stuff(foo: &impl FooBuilder) { let inner = foo.inner(); &inner[KeyA]; &inner[KeyB]; &inner[KeyC]; } fn main() {} </ins>


Question:
<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Given that it doesn't reproduce on godbolt I guess this is apple specific?.
I can reproduce it in playground: godbolt builds Rust code as by default.
Assigning as and removing .
There is no need for containing . Renaming to anything and make it is suffice. The error traces back to 1.0 Rust release:
here is the unwrap to blame.
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.

<ins> // check-pass #![feature(trait_alias)] struct Bar; trait Foo {} impl Foo for Bar {} trait Baz = Foo where Bar: Foo; fn new() -> impl Baz { Bar } fn main() { let _ = new(); } </ins>


Question:
<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Given that it doesn't reproduce on godbolt I guess this is apple specific?.
I can reproduce it in playground: godbolt builds Rust code as by default.
Assigning as and removing .
There is no need for containing . Renaming to anything and make it is suffice. The error traces back to 1.0 Rust release:
here is the unwrap to blame.
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.

<ins> #![feature(unsize)] use std::marker::Unsize; pub trait CastTo<T: ?Sized>: Unsize<T> { fn cast_to(&self) -> &T; } impl<T: ?Sized, U: ?Sized + Unsize<T>> CastTo<T> for U { fn cast_to(&self) -> &T { self } } impl<T: ?Sized> Cast for T {} pub trait Cast { fn cast<T: ?Sized>(&self) -> &T where Self: CastTo<T>, { self } } pub trait Foo: CastTo<[i32]> {} impl Foo for [i32; 0] {} fn main() { let x: &dyn Foo = &[]; let x = x.cast::<[i32]>(); //~^ ERROR: the trait bound `dyn Foo: CastTo<[i32]>` is not satisfied } </ins>


Question:
<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Given that it doesn't reproduce on godbolt I guess this is apple specific?.
I can reproduce it in playground: godbolt builds Rust code as by default.
Assigning as and removing .
There is no need for containing . Renaming to anything and make it is suffice. The error traces back to 1.0 Rust release:
here is the unwrap to blame.
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.

<ins> error[E0277]: the trait bound `dyn Foo: CastTo<[i32]>` is not satisfied --> $DIR/issue-71659.rs:30:15 | LL |     let x = x.cast::<[i32]>(); |               ^^^^ the trait `CastTo<[i32]>` is not implemented for `dyn Foo` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>


Question:
<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Given that it doesn't reproduce on godbolt I guess this is apple specific?.
I can reproduce it in playground: godbolt builds Rust code as by default.
Assigning as and removing .
There is no need for containing . Renaming to anything and make it is suffice. The error traces back to 1.0 Rust release:
here is the unwrap to blame.
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.

<ins> pub trait Callback { fn cb(); } pub trait Processing { type Call: Callback; } fn f<P: Processing + ?Sized>() { P::Call::cb(); } fn main() { struct MyCall; f::<dyn Processing<Call = MyCall>>(); //~^ ERROR: the trait bound `MyCall: Callback` is not satisfied } </ins>


Question:
<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Given that it doesn't reproduce on godbolt I guess this is apple specific?.
I can reproduce it in playground: godbolt builds Rust code as by default.
Assigning as and removing .
There is no need for containing . Renaming to anything and make it is suffice. The error traces back to 1.0 Rust release:
here is the unwrap to blame.
Triage: This is no longer ICE with the latest nightly, marking as E-needs-test.

<ins> error[E0277]: the trait bound `MyCall: Callback` is not satisfied --> $DIR/issue-75707.rs:15:5 | LL | fn f<P: Processing + ?Sized>() { |         ---------- required by this bound in `f` ... LL |     f::<dyn Processing<Call = MyCall>>(); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Callback` is not implemented for `MyCall` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>


Question:
! Note that "Ayu" is already highlighted, it happens to mdbook too. CC
The contrast is too small indeed. Want to send a fix?
I will pass on this, I sent too many pull requests today, I can do this maybe another day (a few days) or if anyone is interested can take up this task before I do.
I'll certainly send a PR tomorrow then.

} #theme-choices > button:hover, #theme-choices > button:focus { <del> background-color: rgba(70, 70, 70, 0.33); </del> <ins> background-color: rgba(110, 110, 110, 0.33); </ins> } @media (max-width: 700px) {


Question:
This code (): prints out This is pretty unhelpful for beginners - normally this happens when they try to use in a closure, which tells them they need async: But when they do they get an error about async being unstable, which they have no idea how to solve. The fix is to remove the pipe symbols: However, this requires knowledge that async blocks desugar internally into closures, which is not at all clear from the syntax. It would be better for the compiler to suggest it:
Hey, I saw this and it looked like it might be easy so I took a shot with I haven't fixed the tests yet because I wasn't sure if this approach is reasonable or not. You end up with Re-ordering the note and help, or adding a nested span on to put the help would be considerably more involved.
Given the current is equivalent to , it may be preferable to suggest instead of .
the point of this is that the user didn't mean though. If you add then you can no longer await it: For context, the original code was something like , where the user tried to use outside of an async function.
Thanks for clarifying. What suggestion is preferable seems to depend on the expected return type. Perhaps it is preferable to have both notes?

use tracing::debug; macro_rules! gate_feature_fn { <ins> ($visitor: expr, $has_feature: expr, $span: expr, $name: expr, $explain: expr, $help: expr) => {{ let (visitor, has_feature, span, name, explain, help) = (&*$visitor, $has_feature, $span, $name, $explain, $help); let has_feature: bool = has_feature(visitor.features); debug!("gate_feature(feature = {:?}, span = {:?}); has? {}", name, span, has_feature); if !has_feature && !span.allows_unstable($name) { feature_err_issue(&visitor.sess.parse_sess, name, span, GateIssue::Language, explain) .help(help) .emit(); } }}; </ins> ($visitor: expr, $has_feature: expr, $span: expr, $name: expr, $explain: expr) => {{ let (visitor, has_feature, span, name, explain) = (&*$visitor, $has_feature, $span, $name, $explain);


Question:
This code (): prints out This is pretty unhelpful for beginners - normally this happens when they try to use in a closure, which tells them they need async: But when they do they get an error about async being unstable, which they have no idea how to solve. The fix is to remove the pipe symbols: However, this requires knowledge that async blocks desugar internally into closures, which is not at all clear from the syntax. It would be better for the compiler to suggest it:
Hey, I saw this and it looked like it might be easy so I took a shot with I haven't fixed the tests yet because I wasn't sure if this approach is reasonable or not. You end up with Re-ordering the note and help, or adding a nested span on to put the help would be considerably more involved.
Given the current is equivalent to , it may be preferable to suggest instead of .
the point of this is that the user didn't mean though. If you add then you can no longer await it: For context, the original code was something like , where the user tried to use outside of an async function.
Thanks for clarifying. What suggestion is preferable seems to depend on the expected return type. Perhaps it is preferable to have both notes?

} macro_rules! gate_feature_post { <ins> ($visitor: expr, $feature: ident, $span: expr, $explain: expr, $help: expr) => { gate_feature_fn!($visitor, |x: &Features| x.$feature, $span, sym::$feature, $explain, $help) }; </ins> ($visitor: expr, $feature: ident, $span: expr, $explain: expr) => { gate_feature_fn!($visitor, |x: &Features| x.$feature, $span, sym::$feature, $explain) };


Question:
This code (): prints out This is pretty unhelpful for beginners - normally this happens when they try to use in a closure, which tells them they need async: But when they do they get an error about async being unstable, which they have no idea how to solve. The fix is to remove the pipe symbols: However, this requires knowledge that async blocks desugar internally into closures, which is not at all clear from the syntax. It would be better for the compiler to suggest it:
Hey, I saw this and it looked like it might be easy so I took a shot with I haven't fixed the tests yet because I wasn't sure if this approach is reasonable or not. You end up with Re-ordering the note and help, or adding a nested span on to put the help would be considerably more involved.
Given the current is equivalent to , it may be preferable to suggest instead of .
the point of this is that the user didn't mean though. If you add then you can no longer await it: For context, the original code was something like , where the user tried to use outside of an async function.
Thanks for clarifying. What suggestion is preferable seems to depend on the expected return type. Perhaps it is preferable to have both notes?

let spans = sess.parse_sess.gated_spans.spans.borrow(); macro_rules! gate_all { <ins> ($gate:ident, $msg:literal, $help:literal) => { if let Some(spans) = spans.get(&sym::$gate) { for span in spans { gate_feature_post!(&visitor, $gate, *span, $msg, $help); } } }; </ins> ($gate:ident, $msg:literal) => { if let Some(spans) = spans.get(&sym::$gate) { for span in spans {


Question:
This code (): prints out This is pretty unhelpful for beginners - normally this happens when they try to use in a closure, which tells them they need async: But when they do they get an error about async being unstable, which they have no idea how to solve. The fix is to remove the pipe symbols: However, this requires knowledge that async blocks desugar internally into closures, which is not at all clear from the syntax. It would be better for the compiler to suggest it:
Hey, I saw this and it looked like it might be easy so I took a shot with I haven't fixed the tests yet because I wasn't sure if this approach is reasonable or not. You end up with Re-ordering the note and help, or adding a nested span on to put the help would be considerably more involved.
Given the current is equivalent to , it may be preferable to suggest instead of .
the point of this is that the user didn't mean though. If you add then you can no longer await it: For context, the original code was something like , where the user tried to use outside of an async function.
Thanks for clarifying. What suggestion is preferable seems to depend on the expected return type. Perhaps it is preferable to have both notes?

} gate_all!(if_let_guard, "`if let` guard is not implemented"); gate_all!(let_chains, "`let` expressions in this position are experimental"); <del> gate_all!(async_closure, "async closures are unstable"); </del> <ins> gate_all!( async_closure, "async closures are unstable", "to use an async block, remove the `||`: `async {`" ); </ins> gate_all!(generators, "yield syntax is experimental"); gate_all!(or_patterns, "or-patterns syntax is experimental"); gate_all!(raw_ref_op, "raw address of syntax is experimental");


Question:
This code (): prints out This is pretty unhelpful for beginners - normally this happens when they try to use in a closure, which tells them they need async: But when they do they get an error about async being unstable, which they have no idea how to solve. The fix is to remove the pipe symbols: However, this requires knowledge that async blocks desugar internally into closures, which is not at all clear from the syntax. It would be better for the compiler to suggest it:
Hey, I saw this and it looked like it might be easy so I took a shot with I haven't fixed the tests yet because I wasn't sure if this approach is reasonable or not. You end up with Re-ordering the note and help, or adding a nested span on to put the help would be considerably more involved.
Given the current is equivalent to , it may be preferable to suggest instead of .
the point of this is that the user didn't mean though. If you add then you can no longer await it: For context, the original code was something like , where the user tried to use outside of an async function.
Thanks for clarifying. What suggestion is preferable seems to depend on the expected return type. Perhaps it is preferable to have both notes?

} else { Async::No }; <del> if let Async::Yes { span, .. } = asyncness { // Feature-gate `async ||` closures. self.sess.gated_spans.gate(sym::async_closure, span); } </del> let capture_clause = self.parse_capture_clause(); let decl = self.parse_fn_block_decl()?;


Question:
This code (): prints out This is pretty unhelpful for beginners - normally this happens when they try to use in a closure, which tells them they need async: But when they do they get an error about async being unstable, which they have no idea how to solve. The fix is to remove the pipe symbols: However, this requires knowledge that async blocks desugar internally into closures, which is not at all clear from the syntax. It would be better for the compiler to suggest it:
Hey, I saw this and it looked like it might be easy so I took a shot with I haven't fixed the tests yet because I wasn't sure if this approach is reasonable or not. You end up with Re-ordering the note and help, or adding a nested span on to put the help would be considerably more involved.
Given the current is equivalent to , it may be preferable to suggest instead of .
the point of this is that the user didn't mean though. If you add then you can no longer await it: For context, the original code was something like , where the user tried to use outside of an async function.
Thanks for clarifying. What suggestion is preferable seems to depend on the expected return type. Perhaps it is preferable to have both notes?

} }; <ins> if let Async::Yes { span, .. } = asyncness { // Feature-gate `async ||` closures. self.sess.gated_spans.gate(sym::async_closure, span); } </ins> Ok(self.mk_expr( lo.to(body.span), ExprKind::Closure(capture_clause, asyncness, movability, decl, body, lo.to(decl_hi)),


Question:
This code (): prints out This is pretty unhelpful for beginners - normally this happens when they try to use in a closure, which tells them they need async: But when they do they get an error about async being unstable, which they have no idea how to solve. The fix is to remove the pipe symbols: However, this requires knowledge that async blocks desugar internally into closures, which is not at all clear from the syntax. It would be better for the compiler to suggest it:
Hey, I saw this and it looked like it might be easy so I took a shot with I haven't fixed the tests yet because I wasn't sure if this approach is reasonable or not. You end up with Re-ordering the note and help, or adding a nested span on to put the help would be considerably more involved.
Given the current is equivalent to , it may be preferable to suggest instead of .
the point of this is that the user didn't mean though. If you add then you can no longer await it: For context, the original code was something like , where the user tried to use outside of an async function.
Thanks for clarifying. What suggestion is preferable seems to depend on the expected return type. Perhaps it is preferable to have both notes?

| = note: see issue #62290 <https://github.com/rust-lang/rust/issues/62290> for more information = help: add `#![feature(async_closure)]` to the crate attributes to enable <ins> = help: to use an async block, remove the `||`: `async {` </ins> error: aborting due to previous error


Question:
This code (): prints out This is pretty unhelpful for beginners - normally this happens when they try to use in a closure, which tells them they need async: But when they do they get an error about async being unstable, which they have no idea how to solve. The fix is to remove the pipe symbols: However, this requires knowledge that async blocks desugar internally into closures, which is not at all clear from the syntax. It would be better for the compiler to suggest it:
Hey, I saw this and it looked like it might be easy so I took a shot with I haven't fixed the tests yet because I wasn't sure if this approach is reasonable or not. You end up with Re-ordering the note and help, or adding a nested span on to put the help would be considerably more involved.
Given the current is equivalent to , it may be preferable to suggest instead of .
the point of this is that the user didn't mean though. If you add then you can no longer await it: For context, the original code was something like , where the user tried to use outside of an async function.
Thanks for clarifying. What suggestion is preferable seems to depend on the expected return type. Perhaps it is preferable to have both notes?

} fn f5() { <del> async //~ ERROR async closures are unstable </del> <ins> async </ins> let x = 0; //~ ERROR expected one of `move`, `|`, or `||`, found keyword `let` }


Question:
This code (): prints out This is pretty unhelpful for beginners - normally this happens when they try to use in a closure, which tells them they need async: But when they do they get an error about async being unstable, which they have no idea how to solve. The fix is to remove the pipe symbols: However, this requires knowledge that async blocks desugar internally into closures, which is not at all clear from the syntax. It would be better for the compiler to suggest it:
Hey, I saw this and it looked like it might be easy so I took a shot with I haven't fixed the tests yet because I wasn't sure if this approach is reasonable or not. You end up with Re-ordering the note and help, or adding a nested span on to put the help would be considerably more involved.
Given the current is equivalent to , it may be preferable to suggest instead of .
the point of this is that the user didn't mean though. If you add then you can no longer await it: For context, the original code was something like , where the user tried to use outside of an async function.
Thanks for clarifying. What suggestion is preferable seems to depend on the expected return type. Perhaps it is preferable to have both notes?

LL |         let x = 0; |         ^^^ unexpected token <del> error[E0658]: async closures are unstable --> $DIR/block-no-opening-brace.rs:29:5 | LL |     async |     ^^^^^ | = note: see issue #62290 <https://github.com/rust-lang/rust/issues/62290> for more information = help: add `#![feature(async_closure)]` to the crate attributes to enable error: aborting due to 6 previous errors </del> <ins> error: aborting due to 5 previous errors </ins> <del> For more information about this error, try `rustc --explain E0658`. </del>


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: I see similar behavior in stable : The example always succeeds to compile the first time, but uses a large amount of time and memory. : Upon incremental re-compilation, I almost always see one of the following errors. I saw other open issues with a similar error message as the 1.46.0 output below, but in this one the error is affected by the value the array was filled with. : Running sometimes yields a different yet similar error: On 1.46.0: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pOn 1.46.0: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
do you know if this is still a problem for you? claim
On 1.66.0, I still get an error upon incremental recompilation with the same code: <details<summary<strongBacktrace</strong</summary</details
Oh wow I didn't know anyone actually hit this so long ago! I turned this into a much nicer panic a few months ago:

trace!("encoding {} further alloc ids", new_n - n); for idx in n..new_n { let id = self.interpret_allocs[idx]; <del> let pos = self.position() as u32; </del> <ins> let pos = self.position() as u64; </ins> interpret_alloc_index.push(pos); interpret::specialized_encode_alloc_id(self, tcx, id); }


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: I see similar behavior in stable : The example always succeeds to compile the first time, but uses a large amount of time and memory. : Upon incremental re-compilation, I almost always see one of the following errors. I saw other open issues with a similar error message as the 1.46.0 output below, but in this one the error is affected by the value the array was filled with. : Running sometimes yields a different yet similar error: On 1.46.0: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pOn 1.46.0: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
do you know if this is still a problem for you? claim
On 1.66.0, I still get an error upon incremental recompilation with the same code: <details<summary<strongBacktrace</strong</summary</details
Oh wow I didn't know anyone actually hit this so long ago! I turned this into a much nicer panic a few months ago:

traits: LazyArray<DefIndex>, impls: LazyArray<TraitImpls>, incoherent_impls: LazyArray<IncoherentImpls>, <del> interpret_alloc_index: LazyArray<u32>, </del> <ins> interpret_alloc_index: LazyArray<u64>, </ins> proc_macro_data: Option<ProcMacroData>, tables: LazyTables,


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: I see similar behavior in stable : The example always succeeds to compile the first time, but uses a large amount of time and memory. : Upon incremental re-compilation, I almost always see one of the following errors. I saw other open issues with a similar error message as the 1.46.0 output below, but in this one the error is affected by the value the array was filled with. : Running sometimes yields a different yet similar error: On 1.46.0: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pOn 1.46.0: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
do you know if this is still a problem for you? claim
On 1.66.0, I still get an error upon incremental recompilation with the same code: <details<summary<strongBacktrace</strong</summary</details
Oh wow I didn't know anyone actually hit this so long ago! I turned this into a much nicer panic a few months ago:

// For each `AllocId`, we keep track of which decoding state it's currently in. decoding_state: Vec<Lock<State>>, // The offsets of each allocation in the data stream. <del> data_offsets: Vec<u32>, </del> <ins> data_offsets: Vec<u64>, </ins> } impl AllocDecodingState {


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: I see similar behavior in stable : The example always succeeds to compile the first time, but uses a large amount of time and memory. : Upon incremental re-compilation, I almost always see one of the following errors. I saw other open issues with a similar error message as the 1.46.0 output below, but in this one the error is affected by the value the array was filled with. : Running sometimes yields a different yet similar error: On 1.46.0: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pOn 1.46.0: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
do you know if this is still a problem for you? claim
On 1.66.0, I still get an error upon incremental recompilation with the same code: <details<summary<strongBacktrace</strong</summary</details
Oh wow I didn't know anyone actually hit this so long ago! I turned this into a much nicer panic a few months ago:

AllocDecodingSession { state: self, session_id } } <del> pub fn new(data_offsets: Vec<u32>) -> Self { </del> <ins> pub fn new(data_offsets: Vec<u64>) -> Self { </ins> let decoding_state = std::iter::repeat_with(|| Lock::new(State::Empty)).take(data_offsets.len()).collect();


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: I see similar behavior in stable : The example always succeeds to compile the first time, but uses a large amount of time and memory. : Upon incremental re-compilation, I almost always see one of the following errors. I saw other open issues with a similar error message as the 1.46.0 output below, but in this one the error is affected by the value the array was filled with. : Running sometimes yields a different yet similar error: On 1.46.0: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pOn 1.46.0: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
do you know if this is still a problem for you? claim
On 1.66.0, I still get an error upon incremental recompilation with the same code: <details<summary<strongBacktrace</strong</summary</details
Oh wow I didn't know anyone actually hit this so long ago! I turned this into a much nicer panic a few months ago:

query_result_index: EncodedDepNodeIndex, side_effects_index: EncodedDepNodeIndex, // The location of all allocations. <del> interpret_alloc_index: Vec<u32>, </del> <ins> // Most uses only need values up to u32::MAX, but benchmarking indicates that we can use a u64 // without measurable overhead. This permits larger const allocations without ICEing. interpret_alloc_index: Vec<u64>, </ins> // See `OnDiskCache.syntax_contexts` syntax_contexts: FxHashMap<u32, AbsoluteBytePos>, // See `OnDiskCache.expn_data`


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: I see similar behavior in stable : The example always succeeds to compile the first time, but uses a large amount of time and memory. : Upon incremental re-compilation, I almost always see one of the following errors. I saw other open issues with a similar error message as the 1.46.0 output below, but in this one the error is affected by the value the array was filled with. : Running sometimes yields a different yet similar error: On 1.46.0: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pOn 1.46.0: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
do you know if this is still a problem for you? claim
On 1.66.0, I still get an error upon incremental recompilation with the same code: <details<summary<strongBacktrace</strong</summary</details
Oh wow I didn't know anyone actually hit this so long ago! I turned this into a much nicer panic a few months ago:

interpret_alloc_index.reserve(new_n - n); for idx in n..new_n { let id = encoder.interpret_allocs[idx]; <del> let pos: u32 = encoder.position().try_into().unwrap(); </del> <ins> let pos: u64 = encoder.position().try_into().unwrap(); </ins> interpret_alloc_index.push(pos); interpret::specialized_encode_alloc_id(&mut encoder, tcx, id); }


Question:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: I see similar behavior in stable : The example always succeeds to compile the first time, but uses a large amount of time and memory. : Upon incremental re-compilation, I almost always see one of the following errors. I saw other open issues with a similar error message as the 1.46.0 output below, but in this one the error is affected by the value the array was filled with. : Running sometimes yields a different yet similar error: On 1.46.0: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pOn 1.46.0: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
do you know if this is still a problem for you? claim
On 1.66.0, I still get an error upon incremental recompilation with the same code: <details<summary<strongBacktrace</strong</summary</details
Oh wow I didn't know anyone actually hit this so long ago! I turned this into a much nicer panic a few months ago:

usize, (), u32, <ins> u64, </ins> bool, std::string::String, crate::metadata::ModChild,


Question:
I believe the error message for E0308 is incorrect. Here it is, with my emphasis on the part that seems incorrect: Isn't this error because the compiler was able to infer the type, but it was not what was expected? For example, in the example provided in the error explanation, the value assigned to is most definitely , and is expected, so the types don't match. modify labels: A-diagnostics D-incorrect D-confusing C-bug
Also the explanation says: between two types: the type the author explicitly assigned, and the type the compiler inferred. Isn't the most common case passing the wrong type to a function? Usually people do not provide a type annotation to a unless it is necessary to help the compiler figure out what concrete type a generic is. Perhaps the explanation could be clarified and expanded upon for that.
You beat me to it :)
Mentoring instructions: Change to have an up-to-date diagnostic and appropriate long description.
On it.
Proposed text:
Overall text looks good. Can you open a PR and -mention me on it?

Expected type did not match the received type. <del> Erroneous code example: </del> <ins> Erroneous code examples: </ins> ```compile_fail,E0308 <del> let x: i32 = "I am not a number!"; //     ~~~   ~~~~~~~~~~~~~~~~~~~~ //      |             | //      |    initializing expression; //      |    compiler infers type `&str` //      | //    type `i32` assigned to variable `x` </del> <ins> fn plus_one(x: i32) -> i32 { x + 1 } plus_one("Not a number"); //       ^^^^^^^^^^^^^^ expected `i32`, found `&str` if "Not a bool" { // ^^^^^^^^^^^^ expected `bool`, found `&str` } let x: f32 = "Not a float"; //     ---   ^^^^^^^^^^^^^ expected `f32`, found `&str` //     | //     expected due to this </ins> ``` <del> This error occurs when the compiler is unable to infer the concrete type of a variable. It can occur in several cases, the most common being a mismatch between two types: the type the author explicitly assigned, and the type the compiler inferred. </del> <ins> This error occurs when an expression was used in a place where the compiler expected an expression of a different type. It can occur in several cases, the most common being when calling a function and passing an argument which has a different type than the matching type in the function declaration. </ins>


Question:
I believe the error message for E0308 is incorrect. Here it is, with my emphasis on the part that seems incorrect: Isn't this error because the compiler was able to infer the type, but it was not what was expected? For example, in the example provided in the error explanation, the value assigned to is most definitely , and is expected, so the types don't match. modify labels: A-diagnostics D-incorrect D-confusing C-bug
Also the explanation says: between two types: the type the author explicitly assigned, and the type the compiler inferred. Isn't the most common case passing the wrong type to a function? Usually people do not provide a type annotation to a unless it is necessary to help the compiler figure out what concrete type a generic is. Perhaps the explanation could be clarified and expanded upon for that.
You beat me to it :)
Mentoring instructions: Change to have an up-to-date diagnostic and appropriate long description.
On it.
Proposed text:
Overall text looks good. Can you open a PR and -mention me on it?

{"message":"mismatched types","code":{"code":"E0308","explanation":"Expected type did not match the received type. <del> Erroneous code example: </del> <ins> Erroneous code examples: </ins> ```compile_fail,E0308 <del> let x: i32 = "I am not a number!"; //     ~~~   ~~~~~~~~~~~~~~~~~~~~ //      |             | //      |    initializing expression; //      |    compiler infers type `&str` //      | //    type `i32` assigned to variable `x` </del> <ins> fn plus_one(x: i32) -> i32 { x + 1 } plus_one("Not a number"); //       ^^^^^^^^^^^^^^ expected `i32`, found `&str` if "Not a bool" { // ^^^^^^^^^^^^ expected `bool`, found `&str` } let x: f32 = "Not a float"; //     ---   ^^^^^^^^^^^^^ expected `f32`, found `&str` //     | //     expected due to this </ins> ``` <del> This error occurs when the compiler is unable to infer the concrete type of a variable. It can occur in several cases, the most common being a mismatch between two types: the type the author explicitly assigned, and the type the compiler inferred. </del> <ins> This error occurs when an expression was used in a place where the compiler expected an expression of a different type. It can occur in several cases, the most common being when calling a function and passing an argument which has a different type than the matching type in the function declaration. </ins> "},"level":"error","spans":[{"file_name":"$DIR/json-bom-plus-crlf-multifile-aux.rs","byte_start":621,"byte_end":622,"line_start":17,"line_end":17,"column_start":22,"column_end":23,"is_primary":true,"text":[{"text":"    let s : String = 1;  // Error in the middle of line.","highlight_start":22,"highlight_end":23}],"label":"expected struct `String`, found integer","suggested_replacement":null,"suggestion_applicability":null,"expansion":null},{"file_name":"$DIR/json-bom-plus-crlf-multifile-aux.rs","byte_start":612,"byte_end":618,"line_start":17,"line_end":17,"column_start":13,"column_end":19,"is_primary":false,"text":[{"text":"    let s : String = 1;  // Error in the middle of line.","highlight_start":13,"highlight_end":19}],"label":"expected due to this","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[{"message":"try using a conversion method","code":null,"level":"help","spans":[{"file_name":"$DIR/json-bom-plus-crlf-multifile-aux.rs","byte_start":621,"byte_end":622,"line_start":17,"line_end":17,"column_start":22,"column_end":23,"is_primary":true,"text":[{"text":"    let s : String = 1;  // Error in the middle of line.","highlight_start":22,"highlight_end":23}],"label":null,"suggested_replacement":"1.to_string()","suggestion_applicability":"MaybeIncorrect","expansion":null}],"children":[],"rendered":null}],"rendered":"$DIR/json-bom-plus-crlf-multifile-aux.rs:17:22: error[E0308]: mismatched types "} {"message":"mismatched types","code":{"code":"E0308","explanation":"Expected type did not match the received type. <del> Erroneous code example: </del> <ins> Erroneous code examples: </ins> ```compile_fail,E0308 <del> let x: i32 = "I am not a number!"; //     ~~~   ~~~~~~~~~~~~~~~~~~~~ //      |             | //      |    initializing expression; //      |    compiler infers type `&str` //      | //    type `i32` assigned to variable `x` </del> <ins> fn plus_one(x: i32) -> i32 { x + 1 } plus_one("Not a number"); //       ^^^^^^^^^^^^^^ expected `i32`, found `&str` if "Not a bool" { // ^^^^^^^^^^^^ expected `bool`, found `&str` } let x: f32 = "Not a float"; //     ---   ^^^^^^^^^^^^^ expected `f32`, found `&str` //     | //     expected due to this </ins> ``` <del> This error occurs when the compiler is unable to infer the concrete type of a variable. It can occur in several cases, the most common being a mismatch between two types: the type the author explicitly assigned, and the type the compiler inferred. </del> <ins> This error occurs when an expression was used in a place where the compiler expected an expression of a different type. It can occur in several cases, the most common being when calling a function and passing an argument which has a different type than the matching type in the function declaration. </ins> "},"level":"error","spans":[{"file_name":"$DIR/json-bom-plus-crlf-multifile-aux.rs","byte_start":681,"byte_end":682,"line_start":19,"line_end":19,"column_start":22,"column_end":23,"is_primary":true,"text":[{"text":"    let s : String = 1","highlight_start":22,"highlight_end":23}],"label":"expected struct `String`, found integer","suggested_replacement":null,"suggestion_applicability":null,"expansion":null},{"file_name":"$DIR/json-bom-plus-crlf-multifile-aux.rs","byte_start":672,"byte_end":678,"line_start":19,"line_end":19,"column_start":13,"column_end":19,"is_primary":false,"text":[{"text":"    let s : String = 1","highlight_start":13,"highlight_end":19}],"label":"expected due to this","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[{"message":"try using a conversion method","code":null,"level":"help","spans":[{"file_name":"$DIR/json-bom-plus-crlf-multifile-aux.rs","byte_start":681,"byte_end":682,"line_start":19,"line_end":19,"column_start":22,"column_end":23,"is_primary":true,"text":[{"text":"    let s : String = 1","highlight_start":22,"highlight_end":23}],"label":null,"suggested_replacement":"1.to_string()","suggestion_applicability":"MaybeIncorrect","expansion":null}],"children":[],"rendered":null}],"rendered":"$DIR/json-bom-plus-crlf-multifile-aux.rs:19:22: error[E0308]: mismatched types "} {"message":"mismatched types","code":{"code":"E0308","explanation":"Expected type did not match the received type. <del> Erroneous code example: </del> <ins> Erroneous code examples: </ins> ```compile_fail,E0308 <del> let x: i32 = "I am not a number!"; //     ~~~   ~~~~~~~~~~~~~~~~~~~~ //      |             | //      |    initializing expression; //      |    compiler infers type `&str` //      | //    type `i32` assigned to variable `x` </del> <ins> fn plus_one(x: i32) -> i32 { x + 1 } plus_one("Not a number"); //       ^^^^^^^^^^^^^^ expected `i32`, found `&str` if "Not a bool" { // ^^^^^^^^^^^^ expected `bool`, found `&str` } let x: f32 = "Not a float"; //     ---   ^^^^^^^^^^^^^ expected `f32`, found `&str` //     | //     expected due to this </ins> ``` <del> This error occurs when the compiler is unable to infer the concrete type of a variable. It can occur in several cases, the most common being a mismatch between two types: the type the author explicitly assigned, and the type the compiler inferred. </del> <ins> This error occurs when an expression was used in a place where the compiler expected an expression of a different type. It can occur in several cases, the most common being when calling a function and passing an argument which has a different type than the matching type in the function declaration. </ins> "},"level":"error","spans":[{"file_name":"$DIR/json-bom-plus-crlf-multifile-aux.rs","byte_start":745,"byte_end":746,"line_start":23,"line_end":23,"column_start":1,"column_end":2,"is_primary":true,"text":[{"text":"1;  // Error after the newline.","highlight_start":1,"highlight_end":2}],"label":"expected struct `String`, found integer","suggested_replacement":null,"suggestion_applicability":null,"expansion":null},{"file_name":"$DIR/json-bom-plus-crlf-multifile-aux.rs","byte_start":735,"byte_end":741,"line_start":22,"line_end":22,"column_start":13,"column_end":19,"is_primary":false,"text":[{"text":"    let s : String =","highlight_start":13,"highlight_end":19}],"label":"expected due to this","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[{"message":"try using a conversion method","code":null,"level":"help","spans":[{"file_name":"$DIR/json-bom-plus-crlf-multifile-aux.rs","byte_start":745,"byte_end":746,"line_start":23,"line_end":23,"column_start":1,"column_end":2,"is_primary":true,"text":[{"text":"1;  // Error after the newline.","highlight_start":1,"highlight_end":2}],"label":null,"suggested_replacement":"1.to_string()","suggestion_applicability":"MaybeIncorrect","expansion":null}],"children":[],"rendered":null}],"rendered":"$DIR/json-bom-plus-crlf-multifile-aux.rs:23:1: error[E0308]: mismatched types "} {"message":"mismatched types","code":{"code":"E0308","explanation":"Expected type did not match the received type. <del> Erroneous code example: </del> <ins> Erroneous code examples: </ins> ```compile_fail,E0308 <del> let x: i32 = "I am not a number!"; //     ~~~   ~~~~~~~~~~~~~~~~~~~~ //      |             | //      |    initializing expression; //      |    compiler infers type `&str` //      | //    type `i32` assigned to variable `x` </del> <ins> fn plus_one(x: i32) -> i32 { x + 1 } plus_one("Not a number"); //       ^^^^^^^^^^^^^^ expected `i32`, found `&str` if "Not a bool" { // ^^^^^^^^^^^^ expected `bool`, found `&str` } let x: f32 = "Not a float"; //     ---   ^^^^^^^^^^^^^ expected `f32`, found `&str` //     | //     expected due to this </ins> ``` <del> This error occurs when the compiler is unable to infer the concrete type of a variable. It can occur in several cases, the most common being a mismatch between two types: the type the author explicitly assigned, and the type the compiler inferred. </del> <ins> This error occurs when an expression was used in a place where the compiler expected an expression of a different type. It can occur in several cases, the most common being when calling a function and passing an argument which has a different type than the matching type in the function declaration. </ins> "},"level":"error","spans":[{"file_name":"$DIR/json-bom-plus-crlf-multifile-aux.rs","byte_start":801,"byte_end":809,"line_start":25,"line_end":26,"column_start":22,"column_end":6,"is_primary":true,"text":[{"text":"    let s : String = (","highlight_start":22,"highlight_end":23},{"text":"    );  // Error spanning the newline.","highlight_start":1,"highlight_end":6}],"label":"expected struct `String`, found `()`","suggested_replacement":null,"suggestion_applicability":null,"expansion":null},{"file_name":"$DIR/json-bom-plus-crlf-multifile-aux.rs","byte_start":792,"byte_end":798,"line_start":25,"line_end":25,"column_start":13,"column_end":19,"is_primary":false,"text":[{"text":"    let s : String = (","highlight_start":13,"highlight_end":19}],"label":"expected due to this","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[],"rendered":"$DIR/json-bom-plus-crlf-multifile-aux.rs:25:22: error[E0308]: mismatched types "} {"message":"aborting due to 4 previous errors","code":null,"level":"error","spans":[],"children":[],"rendered":"error: aborting due to 4 previous errors


Question:
I believe the error message for E0308 is incorrect. Here it is, with my emphasis on the part that seems incorrect: Isn't this error because the compiler was able to infer the type, but it was not what was expected? For example, in the example provided in the error explanation, the value assigned to is most definitely , and is expected, so the types don't match. modify labels: A-diagnostics D-incorrect D-confusing C-bug
Also the explanation says: between two types: the type the author explicitly assigned, and the type the compiler inferred. Isn't the most common case passing the wrong type to a function? Usually people do not provide a type annotation to a unless it is necessary to help the compiler figure out what concrete type a generic is. Perhaps the explanation could be clarified and expanded upon for that.
You beat me to it :)
Mentoring instructions: Change to have an up-to-date diagnostic and appropriate long description.
On it.
Proposed text:
Overall text looks good. Can you open a PR and -mention me on it?

{"message":"mismatched types","code":{"code":"E0308","explanation":"Expected type did not match the received type. <del> Erroneous code example: </del> <ins> Erroneous code examples: </ins> ```compile_fail,E0308 <del> let x: i32 = "I am not a number!"; //     ~~~   ~~~~~~~~~~~~~~~~~~~~ //      |             | //      |    initializing expression; //      |    compiler infers type `&str` //      | //    type `i32` assigned to variable `x` </del> <ins> fn plus_one(x: i32) -> i32 { x + 1 } plus_one("Not a number"); //       ^^^^^^^^^^^^^^ expected `i32`, found `&str` if "Not a bool" { // ^^^^^^^^^^^^ expected `bool`, found `&str` } let x: f32 = "Not a float"; //     ---   ^^^^^^^^^^^^^ expected `f32`, found `&str` //     | //     expected due to this </ins> ``` <del> This error occurs when the compiler is unable to infer the concrete type of a variable. It can occur in several cases, the most common being a mismatch between two types: the type the author explicitly assigned, and the type the compiler inferred. </del> <ins> This error occurs when an expression was used in a place where the compiler expected an expression of a different type. It can occur in several cases, the most common being when calling a function and passing an argument which has a different type than the matching type in the function declaration. </ins> "},"level":"error","spans":[{"file_name":"$DIR/json-bom-plus-crlf.rs","byte_start":606,"byte_end":607,"line_start":16,"line_end":16,"column_start":22,"column_end":23,"is_primary":true,"text":[{"text":"    let s : String = 1;  // Error in the middle of line.","highlight_start":22,"highlight_end":23}],"label":"expected struct `String`, found integer","suggested_replacement":null,"suggestion_applicability":null,"expansion":null},{"file_name":"$DIR/json-bom-plus-crlf.rs","byte_start":597,"byte_end":603,"line_start":16,"line_end":16,"column_start":13,"column_end":19,"is_primary":false,"text":[{"text":"    let s : String = 1;  // Error in the middle of line.","highlight_start":13,"highlight_end":19}],"label":"expected due to this","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[{"message":"try using a conversion method","code":null,"level":"help","spans":[{"file_name":"$DIR/json-bom-plus-crlf.rs","byte_start":606,"byte_end":607,"line_start":16,"line_end":16,"column_start":22,"column_end":23,"is_primary":true,"text":[{"text":"    let s : String = 1;  // Error in the middle of line.","highlight_start":22,"highlight_end":23}],"label":null,"suggested_replacement":"1.to_string()","suggestion_applicability":"MaybeIncorrect","expansion":null}],"children":[],"rendered":null}],"rendered":"$DIR/json-bom-plus-crlf.rs:16:22: error[E0308]: mismatched types "} {"message":"mismatched types","code":{"code":"E0308","explanation":"Expected type did not match the received type. <del> Erroneous code example: </del> <ins> Erroneous code examples: </ins> ```compile_fail,E0308 <del> let x: i32 = "I am not a number!"; //     ~~~   ~~~~~~~~~~~~~~~~~~~~ //      |             | //      |    initializing expression; //      |    compiler infers type `&str` //      | //    type `i32` assigned to variable `x` </del> <ins> fn plus_one(x: i32) -> i32 { x + 1 } plus_one("Not a number"); //       ^^^^^^^^^^^^^^ expected `i32`, found `&str` if "Not a bool" { // ^^^^^^^^^^^^ expected `bool`, found `&str` } let x: f32 = "Not a float"; //     ---   ^^^^^^^^^^^^^ expected `f32`, found `&str` //     | //     expected due to this </ins> ``` <del> This error occurs when the compiler is unable to infer the concrete type of a variable. It can occur in several cases, the most common being a mismatch between two types: the type the author explicitly assigned, and the type the compiler inferred. </del> <ins> This error occurs when an expression was used in a place where the compiler expected an expression of a different type. It can occur in several cases, the most common being when calling a function and passing an argument which has a different type than the matching type in the function declaration. </ins> "},"level":"error","spans":[{"file_name":"$DIR/json-bom-plus-crlf.rs","byte_start":666,"byte_end":667,"line_start":18,"line_end":18,"column_start":22,"column_end":23,"is_primary":true,"text":[{"text":"    let s : String = 1","highlight_start":22,"highlight_end":23}],"label":"expected struct `String`, found integer","suggested_replacement":null,"suggestion_applicability":null,"expansion":null},{"file_name":"$DIR/json-bom-plus-crlf.rs","byte_start":657,"byte_end":663,"line_start":18,"line_end":18,"column_start":13,"column_end":19,"is_primary":false,"text":[{"text":"    let s : String = 1","highlight_start":13,"highlight_end":19}],"label":"expected due to this","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[{"message":"try using a conversion method","code":null,"level":"help","spans":[{"file_name":"$DIR/json-bom-plus-crlf.rs","byte_start":666,"byte_end":667,"line_start":18,"line_end":18,"column_start":22,"column_end":23,"is_primary":true,"text":[{"text":"    let s : String = 1","highlight_start":22,"highlight_end":23}],"label":null,"suggested_replacement":"1.to_string()","suggestion_applicability":"MaybeIncorrect","expansion":null}],"children":[],"rendered":null}],"rendered":"$DIR/json-bom-plus-crlf.rs:18:22: error[E0308]: mismatched types "} {"message":"mismatched types","code":{"code":"E0308","explanation":"Expected type did not match the received type. <del> Erroneous code example: </del> <ins> Erroneous code examples: </ins> ```compile_fail,E0308 <del> let x: i32 = "I am not a number!"; //     ~~~   ~~~~~~~~~~~~~~~~~~~~ //      |             | //      |    initializing expression; //      |    compiler infers type `&str` //      | //    type `i32` assigned to variable `x` </del> <ins> fn plus_one(x: i32) -> i32 { x + 1 } plus_one("Not a number"); //       ^^^^^^^^^^^^^^ expected `i32`, found `&str` if "Not a bool" { // ^^^^^^^^^^^^ expected `bool`, found `&str` } let x: f32 = "Not a float"; //     ---   ^^^^^^^^^^^^^ expected `f32`, found `&str` //     | //     expected due to this </ins> ``` <del> This error occurs when the compiler is unable to infer the concrete type of a variable. It can occur in several cases, the most common being a mismatch between two types: the type the author explicitly assigned, and the type the compiler inferred. </del> <ins> This error occurs when an expression was used in a place where the compiler expected an expression of a different type. It can occur in several cases, the most common being when calling a function and passing an argument which has a different type than the matching type in the function declaration. </ins> "},"level":"error","spans":[{"file_name":"$DIR/json-bom-plus-crlf.rs","byte_start":730,"byte_end":731,"line_start":22,"line_end":22,"column_start":1,"column_end":2,"is_primary":true,"text":[{"text":"1;  // Error after the newline.","highlight_start":1,"highlight_end":2}],"label":"expected struct `String`, found integer","suggested_replacement":null,"suggestion_applicability":null,"expansion":null},{"file_name":"$DIR/json-bom-plus-crlf.rs","byte_start":720,"byte_end":726,"line_start":21,"line_end":21,"column_start":13,"column_end":19,"is_primary":false,"text":[{"text":"    let s : String =","highlight_start":13,"highlight_end":19}],"label":"expected due to this","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[{"message":"try using a conversion method","code":null,"level":"help","spans":[{"file_name":"$DIR/json-bom-plus-crlf.rs","byte_start":730,"byte_end":731,"line_start":22,"line_end":22,"column_start":1,"column_end":2,"is_primary":true,"text":[{"text":"1;  // Error after the newline.","highlight_start":1,"highlight_end":2}],"label":null,"suggested_replacement":"1.to_string()","suggestion_applicability":"MaybeIncorrect","expansion":null}],"children":[],"rendered":null}],"rendered":"$DIR/json-bom-plus-crlf.rs:22:1: error[E0308]: mismatched types "} {"message":"mismatched types","code":{"code":"E0308","explanation":"Expected type did not match the received type. <del> Erroneous code example: </del> <ins> Erroneous code examples: </ins> ```compile_fail,E0308 <del> let x: i32 = "I am not a number!"; //     ~~~   ~~~~~~~~~~~~~~~~~~~~ //      |             | //      |    initializing expression; //      |    compiler infers type `&str` //      | //    type `i32` assigned to variable `x` </del> <ins> fn plus_one(x: i32) -> i32 { x + 1 } plus_one("Not a number"); //       ^^^^^^^^^^^^^^ expected `i32`, found `&str` if "Not a bool" { // ^^^^^^^^^^^^ expected `bool`, found `&str` } let x: f32 = "Not a float"; //     ---   ^^^^^^^^^^^^^ expected `f32`, found `&str` //     | //     expected due to this </ins> ``` <del> This error occurs when the compiler is unable to infer the concrete type of a variable. It can occur in several cases, the most common being a mismatch between two types: the type the author explicitly assigned, and the type the compiler inferred. </del> <ins> This error occurs when an expression was used in a place where the compiler expected an expression of a different type. It can occur in several cases, the most common being when calling a function and passing an argument which has a different type than the matching type in the function declaration. </ins> "},"level":"error","spans":[{"file_name":"$DIR/json-bom-plus-crlf.rs","byte_start":786,"byte_end":794,"line_start":24,"line_end":25,"column_start":22,"column_end":6,"is_primary":true,"text":[{"text":"    let s : String = (","highlight_start":22,"highlight_end":23},{"text":"    );  // Error spanning the newline.","highlight_start":1,"highlight_end":6}],"label":"expected struct `String`, found `()`","suggested_replacement":null,"suggestion_applicability":null,"expansion":null},{"file_name":"$DIR/json-bom-plus-crlf.rs","byte_start":777,"byte_end":783,"line_start":24,"line_end":24,"column_start":13,"column_end":19,"is_primary":false,"text":[{"text":"    let s : String = (","highlight_start":13,"highlight_end":19}],"label":"expected due to this","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[],"rendered":"$DIR/json-bom-plus-crlf.rs:24:22: error[E0308]: mismatched types "} {"message":"aborting due to 4 previous errors","code":null,"level":"error","spans":[],"children":[],"rendered":"error: aborting due to 4 previous errors


Question:
I believe the error message for E0308 is incorrect. Here it is, with my emphasis on the part that seems incorrect: Isn't this error because the compiler was able to infer the type, but it was not what was expected? For example, in the example provided in the error explanation, the value assigned to is most definitely , and is expected, so the types don't match. modify labels: A-diagnostics D-incorrect D-confusing C-bug
Also the explanation says: between two types: the type the author explicitly assigned, and the type the compiler inferred. Isn't the most common case passing the wrong type to a function? Usually people do not provide a type annotation to a unless it is necessary to help the compiler figure out what concrete type a generic is. Perhaps the explanation could be clarified and expanded upon for that.
You beat me to it :)
Mentoring instructions: Change to have an up-to-date diagnostic and appropriate long description.
On it.
Proposed text:
Overall text looks good. Can you open a PR and -mention me on it?

{"message":"mismatched types","code":{"code":"E0308","explanation":"Expected type did not match the received type. <del> Erroneous code example: </del> <ins> Erroneous code examples: </ins> ```compile_fail,E0308 <del> let x: i32 = "I am not a number!"; //     ~~~   ~~~~~~~~~~~~~~~~~~~~ //      |             | //      |    initializing expression; //      |    compiler infers type `&str` //      | //    type `i32` assigned to variable `x` </del> <ins> fn plus_one(x: i32) -> i32 { x + 1 } plus_one("Not a number"); //       ^^^^^^^^^^^^^^ expected `i32`, found `&str` if "Not a bool" { // ^^^^^^^^^^^^ expected `bool`, found `&str` } let x: f32 = "Not a float"; //     ---   ^^^^^^^^^^^^^ expected `f32`, found `&str` //     | //     expected due to this </ins> ``` <del> This error occurs when the compiler is unable to infer the concrete type of a variable. It can occur in several cases, the most common being a mismatch between two types: the type the author explicitly assigned, and the type the compiler inferred. </del> <ins> This error occurs when an expression was used in a place where the compiler expected an expression of a different type. It can occur in several cases, the most common being when calling a function and passing an argument which has a different type than the matching type in the function declaration. </ins> "},"level":"error","spans":[{"file_name":"$DIR/flag-json.rs","byte_start":244,"byte_end":246,"line_start":7,"line_end":7,"column_start":17,"column_end":19,"is_primary":true,"text":[{"text":"    let _: () = 42;","highlight_start":17,"highlight_end":19}],"label":"expected `()`, found integer","suggested_replacement":null,"suggestion_applicability":null,"expansion":null},{"file_name":"$DIR/flag-json.rs","byte_start":239,"byte_end":241,"line_start":7,"line_end":7,"column_start":12,"column_end":14,"is_primary":false,"text":[{"text":"    let _: () = 42;","highlight_start":12,"highlight_end":14}],"label":"expected due to this","suggested_replacement":null,"suggestion_applicability":null,"expansion":null}],"children":[],"rendered":"error[E0308]: mismatched types --> $DIR/flag-json.rs:7:17 |


Question:
The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implementation () [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev-
Ad discussed starting in I’m not convinced this feature carries its weight to be included in the standard library, given that also exists.
may be more useful.
How so? Trying to go beyond "I want to borrow because I want to borrow"
In a similar vein, I was curious if the opposite existed, converting from to : I do not have a specific usecase in mind. My thoughts were likewise around avoiding the copy (small as it may be).
Something kind of like that exists:  It returns because the byte slice might not be aligned properly for an , so it returns the unaligned parts separately. It's also unsafe because it can transmute to any type. A safe version for integers could be possible, but that won't solve the alignment problem.
A good point! The original case had a , which I neglected to show here. You get that "for free" if you store a and have something like the suggested .
Sorry for replying really late here (I accidentally unsubscribed from the issue.) but how should I proceed from here? Remove the function from std as per Simon's suggestion Add another function Though, the one does sound interesting to me although it is unrelated my original use case.
This feature would be useful to make this be a safe conversion. Currently this requires unsafe code. We use this type of abstraction in ; it would also be handy in some serialization-type libraries.
One other suggestion. It would be useful if this method returned a type like (pseudo-code for a newtype that guarantees that the byte array is 4-byte aligned). This would allow for safe two-way <-conversion. In other words, returning is nice in that it remembers the length, but it throws away the alignment. It would be nice if we could also retain the alignment information.
Which "this" are you referring to? Why does not work for you?
I meant that allows the conversion from to to be safe. Right now it requires .
Also: in conjunction with , this feature would also enable safe conversion from to .
Regarding : I believe that would be out of scope for this feature? At least, I am not aware of any machinery in that allows one to say "the returned value is N-byte aligned", so doing that would require a new feature that mimics the crate in .
I think I'm with on this one. Given that this can't (portably) have and , I'm not sure it's worth having as a distinct thing, assuming that the Safe Transmute project lands -- as one of its top two use cases is offering native-endian views into everything where it's safe to do so, including and and such.
Agreed. I think it would be great to wait and see what the Safe Transmute project gives us here.
The use case is valid but a more general mechanism is direly needed here (something like this came up in Portable SIMD discussions).
Opened which removes this feature.

self.to_bits().to_ne_bytes() } <del> /// Return the memory representation of this floating point number as a byte array in /// native byte order. /// /// [`to_ne_bytes`] should be preferred over this whenever possible. /// /// [`to_ne_bytes`]: f32::to_ne_bytes /// /// # Examples /// /// ``` /// #![feature(num_as_ne_bytes)] /// let num = 12.5f32; /// let bytes = num.as_ne_bytes(); /// assert_eq!( ///     bytes, ///     if cfg!(target_endian = "big") { ///         &[0x41, 0x48, 0x00, 0x00] ///     } else { ///         &[0x00, 0x00, 0x48, 0x41] ///     } /// ); /// ``` #[unstable(feature = "num_as_ne_bytes", issue = "76976")] #[inline] pub fn as_ne_bytes(&self) -> &[u8; 4] { // SAFETY: `f32` is a plain old datatype so we can always transmute to it unsafe { &*(self as *const Self as *const _) } } </del> /// Create a floating point value from its representation as a byte array in big endian. /// /// # Examples


Question:
The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implementation () [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev-
Ad discussed starting in I’m not convinced this feature carries its weight to be included in the standard library, given that also exists.
may be more useful.
How so? Trying to go beyond "I want to borrow because I want to borrow"
In a similar vein, I was curious if the opposite existed, converting from to : I do not have a specific usecase in mind. My thoughts were likewise around avoiding the copy (small as it may be).
Something kind of like that exists:  It returns because the byte slice might not be aligned properly for an , so it returns the unaligned parts separately. It's also unsafe because it can transmute to any type. A safe version for integers could be possible, but that won't solve the alignment problem.
A good point! The original case had a , which I neglected to show here. You get that "for free" if you store a and have something like the suggested .
Sorry for replying really late here (I accidentally unsubscribed from the issue.) but how should I proceed from here? Remove the function from std as per Simon's suggestion Add another function Though, the one does sound interesting to me although it is unrelated my original use case.
This feature would be useful to make this be a safe conversion. Currently this requires unsafe code. We use this type of abstraction in ; it would also be handy in some serialization-type libraries.
One other suggestion. It would be useful if this method returned a type like (pseudo-code for a newtype that guarantees that the byte array is 4-byte aligned). This would allow for safe two-way <-conversion. In other words, returning is nice in that it remembers the length, but it throws away the alignment. It would be nice if we could also retain the alignment information.
Which "this" are you referring to? Why does not work for you?
I meant that allows the conversion from to to be safe. Right now it requires .
Also: in conjunction with , this feature would also enable safe conversion from to .
Regarding : I believe that would be out of scope for this feature? At least, I am not aware of any machinery in that allows one to say "the returned value is N-byte aligned", so doing that would require a new feature that mimics the crate in .
I think I'm with on this one. Given that this can't (portably) have and , I'm not sure it's worth having as a distinct thing, assuming that the Safe Transmute project lands -- as one of its top two use cases is offering native-endian views into everything where it's safe to do so, including and and such.
Agreed. I think it would be great to wait and see what the Safe Transmute project gives us here.
The use case is valid but a more general mechanism is direly needed here (something like this came up in Portable SIMD discussions).
Opened which removes this feature.

self.to_bits().to_ne_bytes() } <del> /// Return the memory representation of this floating point number as a byte array in /// native byte order. /// /// [`to_ne_bytes`] should be preferred over this whenever possible. /// /// [`to_ne_bytes`]: f64::to_ne_bytes /// /// # Examples /// /// ``` /// #![feature(num_as_ne_bytes)] /// let num = 12.5f64; /// let bytes = num.as_ne_bytes(); /// assert_eq!( ///     bytes, ///     if cfg!(target_endian = "big") { ///         &[0x40, 0x29, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00] ///     } else { ///         &[0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x29, 0x40] ///     } /// ); /// ``` #[unstable(feature = "num_as_ne_bytes", issue = "76976")] #[inline] pub fn as_ne_bytes(&self) -> &[u8; 8] { // SAFETY: `f64` is a plain old datatype so we can always transmute to it unsafe { &*(self as *const Self as *const _) } } </del> /// Create a floating point value from its representation as a byte array in big endian. /// /// # Examples


Question:
The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implementation () [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev-
Ad discussed starting in I’m not convinced this feature carries its weight to be included in the standard library, given that also exists.
may be more useful.
How so? Trying to go beyond "I want to borrow because I want to borrow"
In a similar vein, I was curious if the opposite existed, converting from to : I do not have a specific usecase in mind. My thoughts were likewise around avoiding the copy (small as it may be).
Something kind of like that exists:  It returns because the byte slice might not be aligned properly for an , so it returns the unaligned parts separately. It's also unsafe because it can transmute to any type. A safe version for integers could be possible, but that won't solve the alignment problem.
A good point! The original case had a , which I neglected to show here. You get that "for free" if you store a and have something like the suggested .
Sorry for replying really late here (I accidentally unsubscribed from the issue.) but how should I proceed from here? Remove the function from std as per Simon's suggestion Add another function Though, the one does sound interesting to me although it is unrelated my original use case.
This feature would be useful to make this be a safe conversion. Currently this requires unsafe code. We use this type of abstraction in ; it would also be handy in some serialization-type libraries.
One other suggestion. It would be useful if this method returned a type like (pseudo-code for a newtype that guarantees that the byte array is 4-byte aligned). This would allow for safe two-way <-conversion. In other words, returning is nice in that it remembers the length, but it throws away the alignment. It would be nice if we could also retain the alignment information.
Which "this" are you referring to? Why does not work for you?
I meant that allows the conversion from to to be safe. Right now it requires .
Also: in conjunction with , this feature would also enable safe conversion from to .
Regarding : I believe that would be out of scope for this feature? At least, I am not aware of any machinery in that allows one to say "the returned value is N-byte aligned", so doing that would require a new feature that mimics the crate in .
I think I'm with on this one. Given that this can't (portably) have and , I'm not sure it's worth having as a distinct thing, assuming that the Safe Transmute project lands -- as one of its top two use cases is offering native-endian views into everything where it's safe to do so, including and and such.
Agreed. I think it would be great to wait and see what the Safe Transmute project gives us here.
The use case is valid but a more general mechanism is direly needed here (something like this came up in Portable SIMD discussions).
Opened which removes this feature.

unsafe { mem::transmute(self) } } <del> /// Return the memory representation of this integer as a byte array in /// native byte order. /// /// [`to_ne_bytes`] should be preferred over this whenever possible. /// /// [`to_ne_bytes`]: Self::to_ne_bytes /// /// # Examples /// /// ``` /// #![feature(num_as_ne_bytes)] #[doc = concat!("let num = ", $swap_op, stringify!($SelfT), ";")] /// let bytes = num.as_ne_bytes(); /// assert_eq!( ///     bytes, ///     if cfg!(target_endian = "big") { #[doc = concat!("        &", $be_bytes)] ///     } else { #[doc = concat!("        &", $le_bytes)] ///     } /// ); /// ``` #[unstable(feature = "num_as_ne_bytes", issue = "76976")] #[inline] pub fn as_ne_bytes(&self) -> &[u8; mem::size_of::<Self>()] { // SAFETY: integers are plain old datatypes so we can always transmute them to // arrays of bytes unsafe { &*(self as *const Self as *const _) } } </del> /// Create an integer value from its representation as a byte array in /// big endian. ///


Question:
The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also used as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [x] Implementation () [ ] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev-
Ad discussed starting in I’m not convinced this feature carries its weight to be included in the standard library, given that also exists.
may be more useful.
How so? Trying to go beyond "I want to borrow because I want to borrow"
In a similar vein, I was curious if the opposite existed, converting from to : I do not have a specific usecase in mind. My thoughts were likewise around avoiding the copy (small as it may be).
Something kind of like that exists:  It returns because the byte slice might not be aligned properly for an , so it returns the unaligned parts separately. It's also unsafe because it can transmute to any type. A safe version for integers could be possible, but that won't solve the alignment problem.
A good point! The original case had a , which I neglected to show here. You get that "for free" if you store a and have something like the suggested .
Sorry for replying really late here (I accidentally unsubscribed from the issue.) but how should I proceed from here? Remove the function from std as per Simon's suggestion Add another function Though, the one does sound interesting to me although it is unrelated my original use case.
This feature would be useful to make this be a safe conversion. Currently this requires unsafe code. We use this type of abstraction in ; it would also be handy in some serialization-type libraries.
One other suggestion. It would be useful if this method returned a type like (pseudo-code for a newtype that guarantees that the byte array is 4-byte aligned). This would allow for safe two-way <-conversion. In other words, returning is nice in that it remembers the length, but it throws away the alignment. It would be nice if we could also retain the alignment information.
Which "this" are you referring to? Why does not work for you?
I meant that allows the conversion from to to be safe. Right now it requires .
Also: in conjunction with , this feature would also enable safe conversion from to .
Regarding : I believe that would be out of scope for this feature? At least, I am not aware of any machinery in that allows one to say "the returned value is N-byte aligned", so doing that would require a new feature that mimics the crate in .
I think I'm with on this one. Given that this can't (portably) have and , I'm not sure it's worth having as a distinct thing, assuming that the Safe Transmute project lands -- as one of its top two use cases is offering native-endian views into everything where it's safe to do so, including and and such.
Agreed. I think it would be great to wait and see what the Safe Transmute project gives us here.
The use case is valid but a more general mechanism is direly needed here (something like this came up in Portable SIMD discussions).
Opened which removes this feature.

unsafe { mem::transmute(self) } } <del> /// Return the memory representation of this integer as a byte array in /// native byte order. /// /// [`to_ne_bytes`] should be preferred over this whenever possible. /// /// [`to_ne_bytes`]: Self::to_ne_bytes /// /// # Examples /// /// ``` /// #![feature(num_as_ne_bytes)] #[doc = concat!("let num = ", $swap_op, stringify!($SelfT), ";")] /// let bytes = num.as_ne_bytes(); /// assert_eq!( ///     bytes, ///     if cfg!(target_endian = "big") { #[doc = concat!("        &", $be_bytes)] ///     } else { #[doc = concat!("        &", $le_bytes)] ///     } /// ); /// ``` #[unstable(feature = "num_as_ne_bytes", issue = "76976")] #[inline] pub fn as_ne_bytes(&self) -> &[u8; mem::size_of::<Self>()] { // SAFETY: integers are plain old datatypes so we can always transmute them to // arrays of bytes unsafe { &*(self as *const Self as *const _) } } </del> /// Create a native endian integer value from its representation /// as a byte array in big endian. ///


Question:
xref: In the of , one of the tests crashed with on s390x, while it passed on every other architecture. The reporter in Red Hat bugzilla found that it happens equally with system LLVM 11 or 10. The crate's also has , but they didn't see any improvement after turning that off. The distro builds run tests in release mode (to avoid recompiling from the main build) with flags in : The tests pass if we don't set , which suggests to me that some relevant (mis)optimization is only triggered with the full unit. The tests are also fine with Fedora's rust-1.45.2, only crashing on rust-1.46.0. I also reproduced the crash on rustup's stable 1.46.0, and I used to narrow down to passing, while crashes. That's ..., which is just (cc I don't know if would affect that, or if it's just triggering something new in LLVM. Here's the reporter's backtrace:
cc , another miscompilation on a tier 2 architecture that appeared after a similar optimization. If the root cause is the same, we should have a better chance of diagnosing it now, since it occurs in a crate's test case instead of while compiling Firefox. cc as well.
Assigning as discussed as part of the and removing .
Is supposed to avoid 's changes? That was mentioned in zulip , but I still get the crash with that option on nightly-2020-07-06.
No. That person was mistaken. Drop elaboration runs unconditionally as part of "".
Updating for cross-reference: I tried in , but it didn't help.
As a sanity check, was there any difference in the generated MIR for ? I tested the flag locally and it worked, but we should make sure. If there's no trivial error with the flag, I'm not sure what's going on. I guess we could with the more precise version of but the less precise version of (that was the status quo before ). I would be surprised if we had a miscompilation when using the precise version of both () or the imprecise version of both ( with or a release prior to ) but not with one precise and one imprecise (a release between and ).
Here are the test's after : They were compiled on Fedora Rawhide (34), in case anyone wants to find libraries to actually run the test executables.
Here's for reference: From : The error we get during the test case is , , "No such file or directory", which prints fine. With , the assembly after printing is: I believe that 2 is comparing the tag, where only needs dropping. When I step through, that branch is taken to skip ahead. Otherwise, you can see that it would load (offset 8 from before) for the into , then proceed to dereference that pointer. With , the assembly after printing is: Looks similar with 2, but I don't really speak SystemZ to guess what and are doing. But in the debugger I see that this branch is not taken, and then it loads a garbage pointer into (always seems to be ). The load of is where we .
Found the instruction reference... is Load Logical Immediate (low high) is Add (64), Condition code set So it seems to be clobbering the condition. I'm guessing the revised enum drops just exposed an existing codegen bug.
Nice! Since I didn't want you to have all the fun, here is the LLVM IR for the relevant section. The first basic block is the comparison with the enum discriminant of and the second is the first piece of drop glue. The structure looks to be the exact same, but there are additional annotations in the one with the miscompilation. I think these are correct in a vacuum, but I don't have enough LLVM knowledge to say for sure. I certainly don't have enough to hypothesize why they caused the instruction scheduler to forget all about the need to preserve flags/condition codes. 2020-07-05: 2020-07-06:
gets special treatment -- -- did something about your patch affect that visibility? I'm guessing, maybe before it was dropped indirectly through ( pending ), but with the more precise drops it may be dropped by value? ( does get .) Or if it used a raw before (like ), that doesn't get any annotations. Of course the trait uses , but I don't know what it looks like when an implicit MIR is elaborated.
In the MIR for the "precise" version, we move the error variant into a local, then drop the local. In the MIR for the imprecise version, we check the drop flag for the variant, then drop that projection. As you alluded to, perhaps there's some difference in how we were emitting LLVM IR for drops of locals vs drops of projections? I'm not an expert on codegen. However, given that this miscompilation is present on the latest master even without "precise" drop elaboration, we must have eliminated this difference at some point. Indeed, the declarations persist even with precise drop elaboration disabled on a recent : <details<summary<b -Zprecise-enum-drop-elaboration=no</b</summary</detailsOne thing occurs to me now that didn't last night: These lines seem to be checking the vtable for the boxed trait object in : However, trait object vtables can definitely alias globally. I don't see how this kind of error would cause the miscompilation we're seeing, but as I said I don't have much LLVM expertise. Regardless, it seems like something we should fix?
The actual vtable should be shared read-only, which is fine for LLVM .
Let's see what LLVM devs say:
It looks like an LLVM patch was accepted:
I'll backport that patch after the LLVM 11.0.0 final rebase lands -- . (I thought about doing that together, but figured it would be better to separate concerns.)

<del> Subproject commit 3c5d47c81d78e9316e971c9870e8bc7c2c449d24 </del> <ins> Subproject commit 77a0125981b293260c9aec6355dff46ec707ab59 </ins>


Question:
ing a value of an empty enum is valid, however ing a reference to a value of an empty enum produces . I tried this code (): I expected to see this happen: The code should compile with no issue, and the function should never actually execute because has no variants and thus cannot be instantiated. Instead, this happened: The bug exists on 1.47.0 and 1.49.0-nightly (2020-10-18 ) running on the playground. I first found this bug on 1.46.0. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is currently working as intended, but maybe we should say so in the diagnostic
Why is this the intended behavior? I find it notably surprising because I can usually replace with , and the commiler takes care to insert (de)references magically. This would be an exception.
I don't recall, but you might be able to find some of the old discussions
I was just reading some discussion on the exhaustive_patterns issue: IIUC, the reason that (where is an uninhabited type) is considered inhabited is because unsafe code can construct an -reference to an uninhabited type (e.g. with or ). I don't know enough to be sure though.
Though unsafe code can also construct an uninhabited without using references; e.g.: () Output: Errors: So maybe what I said in is not correct?
I think the difference is that creating a value of type like you did is Undefined Behavior, but creating a isn't. Try running your code using the MIRI tool (available on the playground under Tools), it usually tells you when you do UB
Indeed, transmuting to didn't make Miri report UB (though attempting to print the value did) but transmuting to did.
Nice. Indeed dereferencing a reference to unintialized memory is also UB. Instructions to fix this: add a test case named after this issue in the folder find where the error message is emitted (somewhere in ) check when the type is and the subtype is uninhabited (which you can test using ) in the above case, add a note to the error message, saying something like "references are always considered inhabited". I'm not sure if we want to mention why. maybe add some related positive and negative tests to make sure we only emit the new note when relevant maybe test and handle cases like as well? modify labels: +E-easy +E-mentor
On the contrary, constructing a which does not reference a valid is instant UB . A value of type is just as invalid as a value of type .
Oh shoot, I understood the opposite. Then I've misunderstood what says in their blog post: Maybe that post is old and things have changed since? Or maybe unintialized memory does not count as an invalid value?
The rules for validity of reference are not finally decided yet, but still being discussed at rust-lang/unsafe-code-guidelines. To not preempt the conclusion of this discussion, the docs declare as much UB as is possible -- we can always relax UB later, but introducing more UB is a breaking change.
Ok, I understand that if we want to have the option to relax this later, then we can't have the compiler rely on it. So we must treat as inhabited. Otherwise we would accept the following but it would become unsound if we relax the UB: So should stay as it currently is and my are still the way to go.
claim
Thanks for taking this on ! Feel free to ask me questions here or on .
Thanks for the warm welcome :) I do have questions, but I already made a preliminary commit to check if I'm going in the right direction: (edited because I missed a file) Is that ok, or is it better if I ask questions before committing, or just make a PR and adapt it?
That commit looks like what we want yes :) Go ahead and make a PR, it's easier to comment on specific bits of the code
For those who (like me) find this after googling "references are always considered inhabited" (the compiler's help message), the current discussion on this topic is happening in
I've a comment here: Which suggests that we consider making it UB to construct such a reference, so that this macro code doesn't confusingly start breaking for empty enums:

)); } } <ins> if let ty::Ref(_, sub_ty, _) = scrut_ty.kind() { if cx.tcx.is_ty_uninhabited_from(cx.module, sub_ty, cx.param_env) { err.note("references are always considered inhabited"); } } </ins> err.emit(); }


Question:
ing a value of an empty enum is valid, however ing a reference to a value of an empty enum produces . I tried this code (): I expected to see this happen: The code should compile with no issue, and the function should never actually execute because has no variants and thus cannot be instantiated. Instead, this happened: The bug exists on 1.47.0 and 1.49.0-nightly (2020-10-18 ) running on the playground. I first found this bug on 1.46.0. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This is currently working as intended, but maybe we should say so in the diagnostic
Why is this the intended behavior? I find it notably surprising because I can usually replace with , and the commiler takes care to insert (de)references magically. This would be an exception.
I don't recall, but you might be able to find some of the old discussions
I was just reading some discussion on the exhaustive_patterns issue: IIUC, the reason that (where is an uninhabited type) is considered inhabited is because unsafe code can construct an -reference to an uninhabited type (e.g. with or ). I don't know enough to be sure though.
Though unsafe code can also construct an uninhabited without using references; e.g.: () Output: Errors: So maybe what I said in is not correct?
I think the difference is that creating a value of type like you did is Undefined Behavior, but creating a isn't. Try running your code using the MIRI tool (available on the playground under Tools), it usually tells you when you do UB
Indeed, transmuting to didn't make Miri report UB (though attempting to print the value did) but transmuting to did.
Nice. Indeed dereferencing a reference to unintialized memory is also UB. Instructions to fix this: add a test case named after this issue in the folder find where the error message is emitted (somewhere in ) check when the type is and the subtype is uninhabited (which you can test using ) in the above case, add a note to the error message, saying something like "references are always considered inhabited". I'm not sure if we want to mention why. maybe add some related positive and negative tests to make sure we only emit the new note when relevant maybe test and handle cases like as well? modify labels: +E-easy +E-mentor
On the contrary, constructing a which does not reference a valid is instant UB . A value of type is just as invalid as a value of type .
Oh shoot, I understood the opposite. Then I've misunderstood what says in their blog post: Maybe that post is old and things have changed since? Or maybe unintialized memory does not count as an invalid value?
The rules for validity of reference are not finally decided yet, but still being discussed at rust-lang/unsafe-code-guidelines. To not preempt the conclusion of this discussion, the docs declare as much UB as is possible -- we can always relax UB later, but introducing more UB is a breaking change.
Ok, I understand that if we want to have the option to relax this later, then we can't have the compiler rely on it. So we must treat as inhabited. Otherwise we would accept the following but it would become unsound if we relax the UB: So should stay as it currently is and my are still the way to go.
claim
Thanks for taking this on ! Feel free to ask me questions here or on .
Thanks for the warm welcome :) I do have questions, but I already made a preliminary commit to check if I'm going in the right direction: (edited because I missed a file) Is that ok, or is it better if I ask questions before committing, or just make a PR and adapt it?
That commit looks like what we want yes :) Go ahead and make a PR, it's easier to comment on specific bits of the code
For those who (like me) find this after googling "references are always considered inhabited" (the compiler's help message), the current discussion on this topic is happening in
I've a comment here: Which suggests that we consider making it UB to construct such a reference, so that this macro code doesn't confusingly start breaking for empty enums:

| = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms = note: the matched value is of type `&!` <ins> = note: references are always considered inhabited </ins> error[E0004]: non-exhaustive patterns: type `Foo` is non-empty --> $DIR/always-inhabited-union-ref.rs:27:11