jiebi/CodeConvo huggingface dataset:
Code change:
This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc ), though we should benchmark the perf considerations around that first. Alternatively we can just not ICE here and instead emit an error. () Errors:
Interesting. ICEs in Miri with are also bugs, so I'd say doing more validation is not the right call. Do you have a backtrace? Which code is responsible for ICEing here and how hard/bad would it be to just error instead?
It's ICEing in and we could indeed just emit a UB error here, but it seems very... odd, since the field access check has very little to do with UB at a first glance. The layout is a union with zero fields, because it's essentially .
TBH this looks like a bug to me. That's the layout of which type, ? It should have a field, and it should not be a union. Cc
It's not a bug. Just like layout for a newtype with a single field is not a bug (E.g. ).
Precisely by analogy with , I think this is a bug. Your has a with exactly 1 field, matching what is declared. It does not have 2 fields which would be the case if it had a "pair layout". So, transparent layout changes the , but it does not change how many "fields" a type is considered to have. Similarly, has 3 fields in its layout, despite still being a . So, correspondingly, should have 1 field.
oh... right. Yea we should totally fix that
This being a layout bug would trivially break codegen, why is only miri affected?
Codegen might skip the field access because the type is uninhabited?
I wouldn't be so sure, codegen calls on layouts a lot without checking. Can the ICE print the whole ? That might be more useful here. EDIT: oh this might be why: we don't check the index at all:
yea but we can't use because that ICEs during const prop in the array case. I have a local branch that I'm playing with to get the entire picture
You can literally remove the assert to get the same effect. But if the field count is wrong I'd rather have an assert in both places and fix the count (if possible).
The full is and so far I haven't figured out how that can happen
Ah, nevermind, I found it:
Ah so that's a micro-optimization. Maybe we should compute the right thing.
computes the layout for structs but keeps returning the never layout for enums without inhabited variants

Related discussion:
text: <ins> // check-pass #[derive(Copy, Clone)] pub struct ChildStdin { inner: AnonPipe, } #[derive(Copy, Clone)] enum AnonPipe {} const FOO: () = { union Foo { a: ChildStdin, b: (), } let x = unsafe { Foo { b: () }.a }; let x = &x.inner; }; fn main() {} </ins>
Code change:
The following ICE's on stable, beta and nightly: <details<summaryBacktrace:</summary</detailsRunning a quick test in godbolt, the first occurrence of the ICE is in stable 1.25. Feel free to close if this is a dupe of
triage: P-medium. has fix in PR (thanks !). Assigning to latter and removing nomination label.

Related discussion:
text: if let hir::ExprKind::Index(ref base, ref index) = e.kind { let mut tables = self.fcx.tables.borrow_mut(); <del> // All valid indexing looks like this; might encounter non-valid indexes at this point if let ty::Ref(_, base_ty, _) = tables.expr_ty_adjusted(&base).kind { let index_ty = tables.expr_ty_adjusted(&index); </del> <ins> // All valid indexing looks like this; might encounter non-valid indexes at this point. let base_ty = tables.expr_ty_adjusted_opt(&base).map(|t| &t.kind); if base_ty.is_none() { // When encountering `return [0][0]` outside of a `fn` body we can encounter a base // that isn't in the type table. We assume more relevant errors have already been // emitted, so we delay an ICE if none have. (#64638) self.tcx().sess.delay_span_bug(e.span, &format!("bad base: `{:?}`", base)); } if let Some(ty::Ref(_, base_ty, _)) = base_ty { let index_ty = tables.expr_ty_adjusted_opt(&index).unwrap_or_else(|| { // When encountering `return [0][0]` outside of a `fn` body we would attempt // to access an unexistend index. We assume that more relevant errors will // already have been emitted, so we only gate on this with an ICE if no // error has been emitted. (#64638) self.tcx().sess.delay_span_bug( e.span, &format!("bad index {:?} for base: `{:?}`", index, base), ); self.fcx.tcx.types.err }); </ins> let index_ty = self.fcx.resolve_vars_if_possible(&index_ty); if base_ty.builtin_index().is_some() && index_ty == self.fcx.tcx.types.usize {
Code change:
The following ICE's on stable, beta and nightly: <details<summaryBacktrace:</summary</detailsRunning a quick test in godbolt, the first occurrence of the ICE is in stable 1.25. Feel free to close if this is a dupe of
triage: P-medium. has fix in PR (thanks !). Assigning to latter and removing nomination label.

Related discussion:
text: <ins> enum Bug { V1 = return [0][0] //~ERROR return statement outside of function body } fn main() {} </ins>
Code change:
The following ICE's on stable, beta and nightly: <details<summaryBacktrace:</summary</detailsRunning a quick test in godbolt, the first occurrence of the ICE is in stable 1.25. Feel free to close if this is a dupe of
triage: P-medium. has fix in PR (thanks !). Assigning to latter and removing nomination label.

Related discussion:
text: <ins> error[E0572]: return statement outside of function body --> $DIR/issue-64620.rs:2:10 | LL |     V1 = return [0][0] |          ^^^^^^^^^^^^^ error: aborting due to previous error For more information about this error, try `rustc --explain E0572`. </ins>
Code change:
Internal compiler error when missing bound on struct. Reproducible on stable/beta/nightly on . Also, not sure if it already has it's own issue, but is causing an illegal instruction error when you run it with on this code as well, which is also reproducible on playground if you turn the backtrace setting on. I tried this code: () I expected to see this happen: Instead, this happened: rustc versions (from playground): <details<summaryBacktrace (note the SIGILL at the end)</summary<p</p</details
cc
triage: P-high, removing nomination label (has PR).

Related discussion:
text: // ignore it.  We can't put it on the struct header anyway. RegionKind::ReLateBound(..) => false, <ins> // This can appear in `where Self: ` bounds (#64855): // //     struct Bar<T>(<Self as Foo>::Type) where Self: ; //     struct Baz<'a>(&'a Self) where Self: ; RegionKind::ReEmpty => false, </ins> // These regions don't appear in types from type declarations: <del> RegionKind::ReEmpty | RegionKind::ReErased </del> <ins> RegionKind::ReErased </ins> | RegionKind::ReClosureBound(..) | RegionKind::ReScope(..) | RegionKind::ReVar(..)
Code change:
Internal compiler error when missing bound on struct. Reproducible on stable/beta/nightly on . Also, not sure if it already has it's own issue, but is causing an illegal instruction error when you run it with on this code as well, which is also reproducible on playground if you turn the backtrace setting on. I tried this code: () I expected to see this happen: Instead, this happened: rustc versions (from playground): <details<summaryBacktrace (note the SIGILL at the end)</summary<p</p</details
cc
triage: P-high, removing nomination label (has PR).

Related discussion:
text: <ins> // check-pass pub struct Bar<'a>(&'a Self) where Self: ; fn main() {} </ins>
Code change:
Internal compiler error when missing bound on struct. Reproducible on stable/beta/nightly on . Also, not sure if it already has it's own issue, but is causing an illegal instruction error when you run it with on this code as well, which is also reproducible on playground if you turn the backtrace setting on. I tried this code: () I expected to see this happen: Instead, this happened: rustc versions (from playground): <details<summaryBacktrace (note the SIGILL at the end)</summary<p</p</details
cc
triage: P-high, removing nomination label (has PR).

Related discussion:
text: <ins> pub trait Foo { type Type; } pub struct Bar<T>(<Self as Foo>::Type) where Self: ; //~^ ERROR the trait bound `Bar<T>: Foo` is not satisfied fn main() {} </ins>
Code change:
Internal compiler error when missing bound on struct. Reproducible on stable/beta/nightly on . Also, not sure if it already has it's own issue, but is causing an illegal instruction error when you run it with on this code as well, which is also reproducible on playground if you turn the backtrace setting on. I tried this code: () I expected to see this happen: Instead, this happened: rustc versions (from playground): <details<summaryBacktrace (note the SIGILL at the end)</summary<p</p</details
cc
triage: P-high, removing nomination label (has PR).

Related discussion:
text: <ins> error[E0277]: the trait bound `Bar<T>: Foo` is not satisfied --> $DIR/issue-64855.rs:5:19 | LL | pub struct Bar<T>(<Self as Foo>::Type) where Self: ; |                   ^^^^^^^^^^^^^^^^^^^ the trait `Foo` is not implemented for `Bar<T>` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>
Code change:
This fails (as expected): However, the help message is wrong: It should suggest instead. Rust version: 1.38.0 (stable)
I would like to pick this up, in case nobody is working on it
go ahead!

Related discussion:
text: use syntax::feature_gate::{GateIssue, emit_feature_err}; use syntax::source_map::{DUMMY_SP, original_sp}; use syntax::symbol::{kw, sym}; <ins> use syntax::util::parser::ExprPrecedence; </ins> use std::cell::{Cell, RefCell, Ref, RefMut}; use std::collections::hash_map::Entry;
Code change:
This fails (as expected): However, the help message is wrong: It should suggest instead. Rust version: 1.38.0 (stable)
I would like to pick this up, in case nobody is working on it
go ahead!

Related discussion:
text: let max_len = receiver.rfind(".").unwrap(); format!("{}{}", &receiver[..max_len], method_call) } else { <del> format!("{}{}", receiver, method_call) </del> <ins> if expr.precedence().order() < ExprPrecedence::MethodCall.order() { format!("({}){}", receiver, method_call) } else { format!("{}{}", receiver, method_call) } </ins> }; Some(if is_struct_pat_shorthand_field { format!("{}: {}", receiver, sugg)
Code change:
This fails (as expected): However, the help message is wrong: It should suggest instead. Rust version: 1.38.0 (stable)
I would like to pick this up, in case nobody is working on it
go ahead!

Related discussion:
text: |                                               ^^^^^^^^^^ |                                               | |                                               expected struct `std::vec::Vec`, found reference <del> |                                               help: try using a conversion method: `&[1, 2, 3].to_vec()` </del> <ins> |                                               help: try using a conversion method: `(&[1, 2, 3]).to_vec()` </ins> | = note: expected type `std::vec::Vec<usize>` found type `&[{integer}; 3]`
Code change:
This fails (as expected): However, the help message is wrong: It should suggest instead. Rust version: 1.38.0 (stable)
I would like to pick this up, in case nobody is working on it
go ahead!

Related discussion:
text: |             ^^^^^ |             | |             cyclic type of infinite size <del> |             help: try using a conversion method: `box x.to_string()` </del> <ins> |             help: try using a conversion method: `(box x).to_string()` </ins> error[E0055]: reached the recursion limit while auto-dereferencing `Foo` --> $DIR/infinite-autoderef.rs:25:5
Code change:
This fails (as expected): However, the help message is wrong: It should suggest instead. Rust version: 1.38.0 (stable)
I would like to pick this up, in case nobody is working on it
go ahead!

Related discussion:
text: x //~ ERROR mismatched types } <ins> fn f() -> String { 1+2 //~ ERROR mismatched types } fn g() -> String { -2 //~ ERROR mismatched types } </ins> fn main() {}
Code change:
This fails (as expected): However, the help message is wrong: It should suggest instead. Rust version: 1.38.0 (stable)
I would like to pick this up, in case nobody is working on it
go ahead!

Related discussion:
text: = note: expected type `X<X<_, std::string::String>, _>` found type `X<X<_, {integer}>, _>` <del> error: aborting due to 6 previous errors </del> <ins> error[E0308]: mismatched types --> $DIR/abridged.rs:54:5 | LL | fn f() -> String { |           ------ expected `std::string::String` because of return type LL |     1+2 |     ^^^ |     | |     expected struct `std::string::String`, found integer |     help: try using a conversion method: `(1+2).to_string()` | = note: expected type `std::string::String` found type `{integer}` error[E0308]: mismatched types --> $DIR/abridged.rs:59:5 | LL | fn g() -> String { |           ------ expected `std::string::String` because of return type LL |     -2 |     ^^ |     | |     expected struct `std::string::String`, found integer |     help: try using a conversion method: `(-2).to_string()` | = note: expected type `std::string::String` found type `{integer}` error: aborting due to 8 previous errors </ins> For more information about this error, try `rustc --explain E0308`.
Code change:
This fails (as expected): However, the help message is wrong: It should suggest instead. Rust version: 1.38.0 (stable)
I would like to pick this up, in case nobody is working on it
go ahead!

Related discussion:
text: |         ^^^^^ |         | |         cyclic type of infinite size <del> |         help: try using a conversion method: `box g.to_string()` </del> <ins> |         help: try using a conversion method: `(box g).to_string()` </ins> error: aborting due to previous error
Code change:
This fails (as expected): However, the help message is wrong: It should suggest instead. Rust version: 1.38.0 (stable)
I would like to pick this up, in case nobody is working on it
go ahead!

Related discussion:
text: |         ^^^^^ |         | |         cyclic type of infinite size <del> |         help: try using a conversion method: `box f.to_string()` </del> <ins> |         help: try using a conversion method: `(box f).to_string()` </ins> error: aborting due to previous error
Code change:
This fails (as expected): However, the help message is wrong: It should suggest instead. Rust version: 1.38.0 (stable)
I would like to pick this up, in case nobody is working on it
go ahead!

Related discussion:
text: |         ^^^^^ |         | |         cyclic type of infinite size <del> |         help: try using a conversion method: `box f.to_string()` </del> <ins> |         help: try using a conversion method: `(box f).to_string()` </ins> error[E0308]: mismatched types --> $DIR/coerce-suggestions.rs:21:9
Code change:
This code: Errors on with this message:
cc
regression in
I'm still building a compiler with graphviz debugging enabled so I can have a closer look, but I have a theory. I believe the problem is that we are too conservative when marking locals as . Because we pessimistically assume that type is , we also assume that type can be mutated through a shared reference. Once a shared reference to it is taken, we assume that all qualifs that could apply to are applied to that local. We should special case zero-sized arrays here, so when the borrow of occurs, it is not marked as indirectly mutable. Perhaps we could assume that zero-sized arrays never actually as well? While this change would solve this particular issue, I believe that this won't solve the problem entirely. What if we take two references to the zero-sized type ()? While the local containing the ZST itself will not be marked as indirectly mutable, the local containing the first borrow will be, which diverges from the old analysis. We may need to base whether a is indirectly mutable on the analysis.

Related discussion:
text: param_env: ty::ParamEnv<'tcx>, } <ins> impl<'tcx> TransferFunction<'_, '_, 'tcx> { /// Returns `true` if this borrow would allow mutation of the `borrowed_place`. fn borrow_allows_mutation( &self, kind: mir::BorrowKind, borrowed_place: &mir::Place<'tcx>, ) -> bool { let borrowed_ty = borrowed_place.ty(self.body, self.tcx).ty; // Zero-sized types cannot be mutated, since there is nothing inside to mutate. // // FIXME: For now, we only exempt arrays of length zero. We need to carefully // consider the effects before extending this to all ZSTs. if let ty::Array(_, len) = borrowed_ty.kind { if len.try_eval_usize(self.tcx, self.param_env) == Some(0) { return false; } } match kind { mir::BorrowKind::Mut { .. } => true, | mir::BorrowKind::Shared | mir::BorrowKind::Shallow | mir::BorrowKind::Unique => !borrowed_ty.is_freeze(self.tcx, self.param_env, DUMMY_SP), } } } </ins> impl<'tcx> Visitor<'tcx> for TransferFunction<'_, '_, 'tcx> { fn visit_rvalue( &mut self,
Code change:
This code: Errors on with this message:
cc
regression in
I'm still building a compiler with graphviz debugging enabled so I can have a closer look, but I have a theory. I believe the problem is that we are too conservative when marking locals as . Because we pessimistically assume that type is , we also assume that type can be mutated through a shared reference. Once a shared reference to it is taken, we assume that all qualifs that could apply to are applied to that local. We should special case zero-sized arrays here, so when the borrow of occurs, it is not marked as indirectly mutable. Perhaps we could assume that zero-sized arrays never actually as well? While this change would solve this particular issue, I believe that this won't solve the problem entirely. What if we take two references to the zero-sized type ()? While the local containing the ZST itself will not be marked as indirectly mutable, the local containing the first borrow will be, which diverges from the old analysis. We may need to base whether a is indirectly mutable on the analysis.

Related discussion:
text: location: Location, ) { if let mir::Rvalue::Ref(_, kind, ref borrowed_place) = *rvalue { <del> let is_mut = match kind { mir::BorrowKind::Mut { .. } => true, | mir::BorrowKind::Shared | mir::BorrowKind::Shallow | mir::BorrowKind::Unique => { !borrowed_place .ty(self.body, self.tcx) .ty .is_freeze(self.tcx, self.param_env, DUMMY_SP) } }; if is_mut { </del> <ins> if self.borrow_allows_mutation(kind, borrowed_place) { </ins> match borrowed_place.base { mir::PlaceBase::Local(borrowed_local) if !borrowed_place.is_indirect() => self.trans.gen(borrowed_local),
Code change:
This code: Errors on with this message:
cc
regression in
I'm still building a compiler with graphviz debugging enabled so I can have a closer look, but I have a theory. I believe the problem is that we are too conservative when marking locals as . Because we pessimistically assume that type is , we also assume that type can be mutated through a shared reference. Once a shared reference to it is taken, we assume that all qualifs that could apply to are applied to that local. We should special case zero-sized arrays here, so when the borrow of occurs, it is not marked as indirectly mutable. Perhaps we could assume that zero-sized arrays never actually as well? While this change would solve this particular issue, I believe that this won't solve the problem entirely. What if we take two references to the zero-sized type ()? While the local containing the ZST itself will not be marked as indirectly mutable, the local containing the first borrow will be, which diverges from the old analysis. We may need to base whether a is indirectly mutable on the analysis.

Related discussion:
text: item.tcx, item.body, item.def_id, <del> &[], </del> <ins> &item.tcx.get_attrs(item.def_id), </ins> &dead_unwinds, old_dataflow::IndirectlyMutableLocals::new(item.tcx, item.body, item.param_env), |_, local| old_dataflow::DebugFormatted::new(&local),
Code change:
This code: Errors on with this message:
cc
regression in
I'm still building a compiler with graphviz debugging enabled so I can have a closer look, but I have a theory. I believe the problem is that we are too conservative when marking locals as . Because we pessimistically assume that type is , we also assume that type can be mutated through a shared reference. Once a shared reference to it is taken, we assume that all qualifs that could apply to are applied to that local. We should special case zero-sized arrays here, so when the borrow of occurs, it is not marked as indirectly mutable. Perhaps we could assume that zero-sized arrays never actually as well? While this change would solve this particular issue, I believe that this won't solve the problem entirely. What if we take two references to the zero-sized type ()? While the local containing the ZST itself will not be marked as indirectly mutable, the local containing the first borrow will be, which diverges from the old analysis. We may need to base whether a is indirectly mutable on the analysis.

Related discussion:
text: <ins> // Several variants of #64945. // This struct is not important, we just use it to put `T` and `'a` in scope for our associated // consts. struct Generic<'a, T>(std::marker::PhantomData<&'a T>); impl<'a, T: 'static> Generic<'a, T> { const EMPTY_SLICE: &'a [T] = { let x: &'a [T] = &[]; x }; const EMPTY_SLICE_REF: &'a &'static [T] = { let x: &'static [T] = &[]; &x //~^ ERROR `x` does not live long enough }; } static mut INTERIOR_MUT_AND_DROP: &'static [std::cell::RefCell<Vec<i32>>] = { let x: &[_] = &[]; x }; static mut INTERIOR_MUT_AND_DROP_REF: &'static &'static [std::cell::RefCell<Vec<i32>>] = { let x: &[_] = &[]; &x //~^ ERROR `x` does not live long enough }; fn main() {} </ins>
Code change:
This code: Errors on with this message:
cc
regression in
I'm still building a compiler with graphviz debugging enabled so I can have a closer look, but I have a theory. I believe the problem is that we are too conservative when marking locals as . Because we pessimistically assume that type is , we also assume that type can be mutated through a shared reference. Once a shared reference to it is taken, we assume that all qualifs that could apply to are applied to that local. We should special case zero-sized arrays here, so when the borrow of occurs, it is not marked as indirectly mutable. Perhaps we could assume that zero-sized arrays never actually as well? While this change would solve this particular issue, I believe that this won't solve the problem entirely. What if we take two references to the zero-sized type ()? While the local containing the ZST itself will not be marked as indirectly mutable, the local containing the first borrow will be, which diverges from the old analysis. We may need to base whether a is indirectly mutable on the analysis.

Related discussion:
text: <ins> error[E0597]: `x` does not live long enough --> $DIR/generic-slice.rs:15:9 | LL | impl<'a, T: 'static> Generic<'a, T> { |      -- lifetime `'a` defined here ... LL |         &x |         ^^ |         | |         borrowed value does not live long enough |         using this value as a constant requires that `x` is borrowed for `'a` LL | LL |     }; |     - `x` dropped here while still borrowed error[E0597]: `x` does not live long enough --> $DIR/generic-slice.rs:27:5 | LL |     &x |     ^^ |     | |     borrowed value does not live long enough |     using this value as a static requires that `x` is borrowed for `'static` LL | LL | }; | - `x` dropped here while still borrowed error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0597`. </ins>