jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // error-pattern: this file contains an unclosed delimiter // error-pattern: this file contains an unclosed delimiter // error-pattern: expected pattern, found `=` // error-pattern: expected one of `)`, `,`, `->`, `where`, or `{`, found `]` // error-pattern: expected item, found `]` fn main() {} fn p([=(} </ins>

Related discussion:
text: <!-- 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. --Another case from : The md5 of is: <!-- 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. --It is test with nightly, beta, and stable versions. : The output is from nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Because we already emit some correct errors a potential fix would be to just remove the problematic and return an empty function body. However there's another problem; call in generates non-existing tokens outside of the file to close all unmatched brackets. That's why we see column 11 in the error message even though column of the last token is 9 in the source file. called by (called by to recover from the invlid argument when seeing which is invalid in pattern context) first generates at column 9 (which is actually the location of ), which I guess (didn't check) shifts to column 10, which is somehow skipped and some other function inserts (couldn't figure out which function) at column 11. As a result we get this error that points to outside of the file
Is there an expected buffer overrun here or is it guarded?
Assigning as discussed as part of the and removing .
I ran  and some finer-grained manual bisection. The regression happened in cc
I'm guessing is because of this code branch: I haven't checked to see how it could even get to it, as looking at the code it should be unreachable.
Actually, this is caused by a different problem (), because if you try the same code without a trailing newline, this behavior doesn't occur (the error message then points to column 10, which is correct, as it is the location of the EOF token). The spurious ]` is an unrelated issue, which I have filed separately ().
Fixed by but there's no regression test for this case, marking as E-needs-test.
Code change:
#[derive(Copy, Clone, Debug)] pub struct Discr<'tcx> { <ins> /// bit representation of the discriminant, so `-128i8` is `0xFF_u128` </ins> pub val: u128, pub ty: Ty<'tcx> } impl<'tcx> fmt::Display for Discr<'tcx> { fn fmt(&self, fmt: &mut fmt::Formatter) -> fmt::Result { <del> if self.ty.is_signed() { write!(fmt, "{}", self.val as i128) } else { write!(fmt, "{}", self.val) </del> <ins> match self.ty.sty { ty::TyInt(ity) => { let bits = ty::tls::with(|tcx| { Integer::from_attr(tcx, SignedInt(ity)).size().bits() }); let x = self.val as i128; // sign extend the raw representation to be an i128 let x = (x << (128 - bits)) >> (128 - bits); write!(fmt, "{}", x) }, _ => write!(fmt, "{}", self.val), </ins> } } }

Related discussion:
text: I was trying to build which pulls in pango 0.1.3 as dependency . While building pango, rustc segfaults  meta: Crash happens in So apparently const eval produces a discriminant that doesn't match any variant's discriminant. more concretely, it happens during a match on which is the only discriminant with as its value.
weird, I am still getting the panic with todays nightly :(
Same backtrace? We do have a regression test for this exact issue
Yeah, backtrace is identical except for the rustc version string in the ICE notes. :/
Fix confirmed, thanks!
Code change:
} enum XYZ { <del> X, //~ ERROR variant is never used Y { //~ ERROR variant is never used </del> <ins> X, //~ ERROR variant is never constructed Y { //~ ERROR variant is never constructed </ins> a: String, b: i32, c: i32,

Related discussion:
text: I was changing some code from integer constants to a proper enum and was greeted by the following warning: The warning sounded weird to me because I was pattern-matching on that damn variant in various places of the code; but I was pointed out to the fact that I wasn't actually creating that value. Maybe the warning should be rewritten to explicitly mention value creation? Cc
cc that looks like your thing
duplicate of
Yup! Closing in favor of that.
Code change:
<ins> #![feature(rustc_attrs)] #[rustc_layout_scalar_valid_range_start(u32::MAX)] //~ ERROR pub struct A(u32); #[rustc_layout_scalar_valid_range_end(1, 2)] //~ ERROR pub struct B(u8); #[rustc_layout_scalar_valid_range_end(a = "a")] //~ ERROR pub struct C(i32); #[rustc_layout_scalar_valid_range_end(1)] //~ ERROR enum E { X = 1, Y = 14, } fn main() { let _ = A(0); let _ = B(0); let _ = C(0); let _ = E::X; } </ins>

Related discussion:
text: <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This isn't really a bug, it's just that it has bad diagnostics because it uses , which is a perma-unstable attribute. I would recommend against reporting bugs that need attributes unless they cause unsoundness.
MCVE:
Should I exclude all test programs that have a line starting with ? Thanks.
I don't personally feel comfortable setting a policy that we'll never fix ICEs with attributes, but they are definitely less likely to be bugs than other ICEs. Note that this isn't sufficient to catch programs that have an attribute, you can have arbitrary macros that play with conditional compilation, like . Catching and will probably hit the common cases, though (you may want to also include inner attributes).
Code change:
<ins> #![feature(rustc_attrs)] #[rustc_layout_scalar_valid_range_start(u32::MAX)] //~ ERROR pub struct A(u32); #[rustc_layout_scalar_valid_range_end(1, 2)] //~ ERROR pub struct B(u8); #[rustc_layout_scalar_valid_range_end(a = "a")] //~ ERROR pub struct C(i32); #[rustc_layout_scalar_valid_range_end(1)] //~ ERROR enum E { X = 1, Y = 14, } fn main() { let _ = A(0); let _ = B(0); let _ = C(0); let _ = E::X; } </ins>

Related discussion:
text: Gives:
cc ICE-ing instead of user error on misuse seems somewhat okay given that it's an internal attribute, IMO.
agreed. We don't protect against mis-use of rustc internal attributes beyond making sure that you can't trivially create buggy code. I don't think we should put any effort into making this nicer to use and instead create the const-generic based replacement.
Code change:
<ins> error[E0277]: the trait bound `[T; _]: From<()>` is not satisfied --> $DIR/hash-tyvid-regression-1.rs:9:5 | LL |     <[T; N.get()]>::try_from(()) |     ^^^^^^^^^^^^^^^^^^^^^^^^ the trait `From<()>` is not implemented for `[T; _]` | = note: required because of the requirements on the impl of `Into<[T; _]>` for `()` = note: required because of the requirements on the impl of `TryFrom<()>` for `[T; _]` note: required by `try_from` --> $SRC_DIR/core/src/convert/mod.rs:LL:COL | LL |     fn try_from(value: T) -> Result<Self, Self::Error>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error[E0308]: mismatched types --> $DIR/hash-tyvid-regression-1.rs:9:5 | LL |     <[T; N.get()]>::try_from(()) |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `()`, found enum `Result` | = note: expected unit type `()` found enum `Result<[T; _], Infallible>` help: consider using a semicolon here | LL |     <[T; N.get()]>::try_from(()); |                                 + help: try adding a return type | LL | -> Result<[T; _], Infallible> where | +++++++++++++++++++++++++++++ error: aborting due to 2 previous errors Some errors have detailed explanations: E0277, E0308. For more information about an error, try `rustc --explain E0277`. </ins>

Related discussion:
text: <!-- 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. --I'm creating this issue mainly because it seems to be a different one than the ones listed in <!-- 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
What command are you running? I tried this code , but I encountered an error that doesn't have a method.
how strange, for me just causes the ice and it doesn't even come to notice that the function is missing. I just ran , and with the newest rustc () I still get the same error as above (in a new cargo project with the code copied from the playground link above).
Just ran again today and still get an ICE. Made the example a bit smaller: Output of (build also fails with the same message): Considering the rustc versions it should be the same that is currently on the playground, however there it does not cause an ICE. Maybe someone could try to reproduce this in a local environment?
can reproduce this locally, not sure why it doesn't ICE on the playground
cc -- it ICEs locally, but not on the playground
Try with ?
That indeed removes the ICE, let me just check which one of the options it is. Adding to the (or profile.release in release mode) section causes the ice to disappear.
That's even weirder. Seems like this is partly an incr-comp bug then.
Note that the ICE occurs in the incr-comp hasher (ICH): So this seems to be an incr-comp bug.
Reposting : So I removed .
Code change:
<ins> error[E0277]: the trait bound `[T; _]: From<()>` is not satisfied --> $DIR/hash-tyvid-regression-1.rs:9:5 | LL |     <[T; N.get()]>::try_from(()) |     ^^^^^^^^^^^^^^^^^^^^^^^^ the trait `From<()>` is not implemented for `[T; _]` | = note: required because of the requirements on the impl of `Into<[T; _]>` for `()` = note: required because of the requirements on the impl of `TryFrom<()>` for `[T; _]` note: required by `try_from` --> $SRC_DIR/core/src/convert/mod.rs:LL:COL | LL |     fn try_from(value: T) -> Result<Self, Self::Error>; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error[E0308]: mismatched types --> $DIR/hash-tyvid-regression-1.rs:9:5 | LL |     <[T; N.get()]>::try_from(()) |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `()`, found enum `Result` | = note: expected unit type `()` found enum `Result<[T; _], Infallible>` help: consider using a semicolon here | LL |     <[T; N.get()]>::try_from(()); |                                 + help: try adding a return type | LL | -> Result<[T; _], Infallible> where | +++++++++++++++++++++++++++++ error: aborting due to 2 previous errors Some errors have detailed explanations: E0277, E0308. For more information about an error, try `rustc --explain E0277`. </ins>

Related discussion:
text: <!-- 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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<details<summary<strongQuery Stack</strong</summary<p</p</details
modify labels to +requires-nightly
The following snippet gives the same ICE. The types are intentionally wrong. <details<summary<strongBacktrace</strong</summary<p</p</details<details<summary<strongQuery Stack</strong</summary<p</p</details
Triage: This is now fixed on the recent nightly, marking as E-needs-test.
Code change:
But it *does not* match `Result<Vec, u8>` or `Result<u8<Vec>>`. <del> ### Changing displayed theme You can change the displayed theme by opening the settings menu (the gear icon in the upper right) and then pick a new one from there. </del> ### Shortcuts Pressing `S` while focused elsewhere on the page will move focus to the

Related discussion:
text: Rustdoc has accumulated a handful of settings that users can toggle as they read docs, but we don't document them anywhere. It would be ideal if we had some documentation about these options in the Rustdoc Book that described their functionality better than the short descriptions shown on the settings page itself. !
I don't mind picking this up, unless you want to do this yourself! I do however have some questions!: The Rustdoc book you mean is right? Do you suggest adding a new section to this book or would you include it in an already existing section? What do you believe is not clear / elaborated enough in the short descriptions? I do not know the specific details of each switch are there any side-effects that are not in the short description?
Triage: no changes. The rustdoc book is that one, ! I am not a rustdoc maintainer these days (cc ) but I would probably make a new section. While the short description is good, I think it would make sense to show the options in slightly more detail, for example, maybe a before/after.
Bit of a late reply :) Do you have something to add to this? Otherwise I will follow what Steve said!
Code change:
nested: Vec<Ty<'tcx>>) -> VtableBuiltinData<PredicateObligation<'tcx>> { <del> let derived_cause = self.derived_cause(obligation, BuiltinDerivedObligation); let obligations = nested.iter().map(|&bound_ty| { // the obligation might be higher-ranked, e.g. for<'a> &'a // int : Copy. In that case, we will wind up with // late-bound regions in the `nested` vector. So for each // one we instantiate to a skolemized region, do our work // to produce something like `&'0 int : Copy`, and then // re-bind it. This is a bit of busy-work but preserves // the invariant that we only manipulate free regions, not // bound ones. self.infcx.try(|snapshot| { let (skol_ty, skol_map) = self.infcx().skolemize_late_bound_regions(&ty::Binder(bound_ty), snapshot); let skol_predicate = util::predicate_for_builtin_bound( self.tcx(), derived_cause.clone(), bound, obligation.recursion_depth + 1, skol_ty); match skol_predicate { Ok(skol_predicate) => Ok(self.infcx().plug_leaks(skol_map, snapshot, &skol_predicate)), Err(ErrorReported) => Err(ErrorReported) } }) }).collect::<Result<_, _>>(); let obligations = match obligations { Ok(o) => o, Err(ErrorReported) => Vec::new(), </del> <ins> let trait_def = match self.tcx().lang_items.from_builtin_kind(bound) { Ok(def_id) => def_id, Err(_) => { self.tcx().sess.bug("builtin trait definition not found"); } </ins> }; <ins> let obligations = self.collect_predicates_for_types(obligation, trait_def, nested); </ins> let obligations = VecPerParamSpace::new(obligations, Vec::new(), Vec::new()); debug!("vtable_builtin_data: obligations={}",

Related discussion:
text: For example, this code does not compile: cc
I think this may be another instance of
Trusting analysis, closing in favor of but adding test case there as well.
(it of course would be good to confirm that this actually is an instance of -- my initial reaction when I saw it was "they might be related ... but wait, wasn't part of the opt-in-builtin-bounds work to be able to move the special case handling of / out into library code...?"; I've only done some rough skimming that makes me think the hypothesis remains plausible.)
Ah either way is fine by me, I personally like fewer issues :). We can reopen once is addressed one way or another if necessary (or if you'd like to reopen now that's also fine by me!)
oh that was really just a note to myself as much as anything else, not a comment on your choice to close this ticket. :)
I don't think this code uses type-contents. If it does, that is itself a bug! Either way, we should keep this open for the time being.
cc
Code change:
nested: Vec<Ty<'tcx>>) -> VtableBuiltinData<PredicateObligation<'tcx>> { <del> let derived_cause = self.derived_cause(obligation, BuiltinDerivedObligation); let obligations = nested.iter().map(|&bound_ty| { // the obligation might be higher-ranked, e.g. for<'a> &'a // int : Copy. In that case, we will wind up with // late-bound regions in the `nested` vector. So for each // one we instantiate to a skolemized region, do our work // to produce something like `&'0 int : Copy`, and then // re-bind it. This is a bit of busy-work but preserves // the invariant that we only manipulate free regions, not // bound ones. self.infcx.try(|snapshot| { let (skol_ty, skol_map) = self.infcx().skolemize_late_bound_regions(&ty::Binder(bound_ty), snapshot); let skol_predicate = util::predicate_for_builtin_bound( self.tcx(), derived_cause.clone(), bound, obligation.recursion_depth + 1, skol_ty); match skol_predicate { Ok(skol_predicate) => Ok(self.infcx().plug_leaks(skol_map, snapshot, &skol_predicate)), Err(ErrorReported) => Err(ErrorReported) } }) }).collect::<Result<_, _>>(); let obligations = match obligations { Ok(o) => o, Err(ErrorReported) => Vec::new(), </del> <ins> let trait_def = match self.tcx().lang_items.from_builtin_kind(bound) { Ok(def_id) => def_id, Err(_) => { self.tcx().sess.bug("builtin trait definition not found"); } </ins> }; <ins> let obligations = self.collect_predicates_for_types(obligation, trait_def, nested); </ins> let obligations = VecPerParamSpace::new(obligations, Vec::new(), Vec::new()); debug!("vtable_builtin_data: obligations={}",

Related discussion:
text: The following doesn't compile, but I believe it should: Error: Even though , and . In fact, this compiles:
should be , because the old definition that didn't use assoc types was . Probably the code that detects builtin bounds wasn't updated to handle associated types. cc
This breaks us in hyper. For now, I'll have to manually , knowing that it's safe.,,
Code change:
target_option_val!(exe_suffix); target_option_val!(staticlib_prefix); target_option_val!(staticlib_suffix); <del> target_option_val!(os_family, "target_family"); </del> <ins> target_option_val!(os_family, "target-family"); </ins> target_option_val!(abi_return_struct_as_int); target_option_val!(is_like_osx); target_option_val!(is_like_solaris);

Related discussion:
text: Hello everyone, this is my first Issue on the Rust project, let me know if I'm doing anthing wrong ! I am in the process of building a library/runtime for the Wii fully written in Rust. To acheive this goal, I need to cross-compile my library to a custom target I named . The json file contains and along other lines to define the architecture. Normally, the build completes without an issue. On the latest nighlty, the compiler fails and return: Of course, is set to in the file, so this shouldn't happen. It most recently worked on: : It fails on this nightly, currently latest at the time of writing: : I can provide any file or other precision if necessary ! Thanks for reading my report !
I was also having the some issue and tracked it to this: That commit broke the equivalence between "target_endian" and "target-endian" by adding a case to the macro without the replace line for it.
cc
I'll fix this today.
Fixed in
I hope this gets merged asap :-)
(Reopening because isn't merged yet.)
Code change:
<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/cannot-infer-type-for-const-param.rs:1:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ error[E0282]: type annotations needed --> $DIR/cannot-infer-type-for-const-param.rs:10:19 | LL |     let _ = Foo::<3>([1, 2, 3]); |                   ^ cannot infer type for `{integer}` error: aborting due to previous error For more information about this error, try `rustc --explain E0282`. </ins>

Related discussion:
text: Following code sample causes a compiler panic. should be .
Also happens on nightly. Likely due to const generics changes (cc
Minimal reproduction:
Another case:
Code change:
/// # Examples /// /// ``` <del> /// # #![feature(duration_as_u128)] </del> /// use std::time::Duration; /// /// let duration = Duration::new(5, 730023852); /// assert_eq!(duration.as_micros(), 5730023); /// ``` <del> #[unstable(feature = "duration_as_u128", issue = "50202")] </del> <ins> #[stable(feature = "duration_as_u128", since = "1.33.0")] </ins> #[inline] pub const fn as_micros(&self) -> u128 { self.secs as u128 * MICROS_PER_SEC as u128 + (self.nanos / NANOS_PER_MICRO) as u128

Related discussion:
text: Duration has historically lacked a way to get the actual number of nanoseconds it contained as a normal Rust type because u64 was of insufficient range, and f64 of insufficient precision. The u128 type solves both issues, so I propose adding an as_nanos function to expose the capability. CC:
I still don't understand why Duration is not allowed to be negative. It bugs me that the SystemTime difference returns a Result<Duration,Errorand returns and error if the time from is after the time to. To me, it should just return a negative Duration (Yes, the System Clock can go backwards). I find it odd that Duration does not support a negative amount.
I think it's about the way you think of . If it's a span of time (like described in the documentation) or an interval, then it must be positive. If it's the distance between two time points, it's negative. You're probably thinking of a distance instead of an interval. That's not necessarily a bad thing, but it's different from what the type is today, and it will never change due to compatibility concerns.
Here is what I take issue with: And....DING! DING! DING! know what, now that I've typed out that code, I can't think of any justifiable reason I would actually want that, so, once again, the thoughtfulness of Rust shows itself. You and the designers of Duration were correct. Negative Duration doesn't make sense (even though it feels like it should).
You can use if you want to measure a duration.
Yes, I'm aware. I guess I think there should be another thing called ClockTimeDifference (that can be neg/pos) and there should be methods on SystemTime that don't return Result<Duration,Error, but, instead return ClockTimeDifference. It could be as simple as:
It can, but the return type of will never change, so it's up to you (or a crate) to implement that.
This is the tracking issue for a feature that adds several specific methods to Duration, not a place to debate general concerns about the Duration type. Your discussion is probably better suited for the site.
Why can't as_millis return an i64?
large durations won't fit into that type.
Pardon my ignorance, but why is this unstable?