jiebi/CodeConvo huggingface dataset:
Change:
let (suitable_region_binding_scope, bound_region) = loop { let def_id = match region.kind() { ty::ReLateParam(fr) => fr.bound_region.get_id()?.as_local()?, <del> ty::ReEarlyParam(ebr) => ebr.def_id.expect_local(), </del> <ins> ty::ReEarlyParam(ebr) => ebr.def_id.as_local()?, </ins> _ => return None, // not a free region }; let scope = self.local_parent(def_id);

Discussion:
I was developing one trait in one crate, changing it to use a lifetime, and forgot to add it to the other crate's implementation. The compiler shows de correct error message but breaks. If I fix the code, adding the lifetime to the trait, de compiler works. If it is in the same crate also works. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Same backtrace as .
Thanks for the minimized test! I'll fix this tomorrow.

<!-- 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. --While I was trying to add lifetimes for picoserve's I got into ICE (1.) had a dep of picoserve as 2. That code isn't finished and should not compile yet <!-- 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. --: has ice files
rustc 1.75.0 ( 2023-12-21) binary: rustc commit-hash: commit-date: 2023-12-21 host: x86_64-unknown-linux-gnu release: 1.75.0 LLVM version: 17.0.6 Here ICE is also present
Backtrace from one of the linked files pasted below for the sake of searchability and preservation: <details<summaryBacktrace</summary</details
Change:
let t_1 = ast_ty_to_ty_crate(fcx.ccx, t); let t_e = expr_ty(tcx, e); <ins> if ty::type_is_nil(tcx, t_e) { tcx.sess.span_err(expr.span, "cast from nil: " + ty_to_str(tcx, expr_ty(tcx, e)) + " as " + ty_to_str(tcx, t_1)); } if ty::type_is_nil(tcx, t_1) { tcx.sess.span_err(expr.span, "cast to nil: " + ty_to_str(tcx, expr_ty(tcx, e)) + " as " + ty_to_str(tcx, t_1)); } </ins> // FIXME there are more forms of cast to support, eventually. if !(   type_is_scalar(fcx, expr.span, t_e) && type_is_scalar(fcx, expr.span, t_1)) {

Discussion:
error: internal compiler error Translating unsupported cast.
Probably shouldn't allow casting nil
The patch above forbids casting from or to nil for now.
Change:
<ins> warning: the feature `non_lifetime_binders` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/bad-sized-cond.rs:1:12 | LL | #![feature(non_lifetime_binders)] |            ^^^^^^^^^^^^^^^^^^^^ | = note: see issue #108185 <https://github.com/rust-lang/rust/issues/108185> for more information = note: `#[warn(incomplete_features)]` on by default error[E0277]: the size for values of type `V` cannot be known at compilation time --> $DIR/bad-sized-cond.rs:17:5 | LL |     foo(); |     ^^^ doesn't have a size known at compile-time | = help: the trait `Sized` is not implemented for `V` note: required by a bound in `foo` --> $DIR/bad-sized-cond.rs:6:15 | LL | pub fn foo() |        --- required by a bound in this LL | where LL |     for<V> V: Sized, |               ^^^^^ required by this bound in `foo` error[E0277]: the size for values of type `V` cannot be known at compilation time --> $DIR/bad-sized-cond.rs:20:5 | LL |     bar(); |     ^^^ doesn't have a size known at compile-time | = help: the trait `Sized` is not implemented for `V` = note: required for `V` to implement `IntoIterator` note: required by a bound in `bar` --> $DIR/bad-sized-cond.rs:12:15 | LL | pub fn bar() |        --- required by a bound in this LL | where LL |     for<V> V: IntoIterator, |               ^^^^^^^^^^^^ required by this bound in `bar` error[E0277]: `V` is not an iterator --> $DIR/bad-sized-cond.rs:20:5 | LL |     bar(); |     ^^^ `V` is not an iterator | = help: the trait `Iterator` is not implemented for `V` = note: required for `V` to implement `IntoIterator` note: required by a bound in `bar` --> $DIR/bad-sized-cond.rs:12:15 | LL | pub fn bar() |        --- required by a bound in this LL | where LL |     for<V> V: IntoIterator, |               ^^^^^^^^^^^^ required by this bound in `bar` error: aborting due to 3 previous errors; 1 warning emitted For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
<!-- 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
I can't reproduce this? On master, that is.
Ah oops, looks like I minimized wrongly, give me a sec...
This should do: `
Minimized -- PR coming up.
Change:
} let pointee = tcx.normalize_associated_type_in_env(&pointee, param_env); <del> if pointee.is_sized(tcx, param_env, DUMMY_SP) { </del> <ins> if pointee.is_sized(tcx.at(DUMMY_SP), param_env) { </ins> return Ok(tcx.intern_layout(LayoutDetails::scalar(self, data_ptr))); }

Discussion:
One example is the method on . Internally it creates a , when it could simply be taking exactly that as an argument. In miri I had to write which just feels a little riddiculous (taking apart the , just to have the method construct it back). There's probably many other similar methods and functions that should be taking a
Can I take this one if no one is working on that ?
it's all yours!
Change:
let mut struct_tree = Self::def(def); // If a `tag` is provided, place it at the start of the layout. <del> if let Some(tag) = tag { size += tag.size(); struct_tree = struct_tree.then(Self::from_tag(tag, cx.tcx)); </del> <ins> if let Some((tag, index, encoding)) = &tag { match encoding { TagEncoding::Direct => { size += tag.size(); } TagEncoding::Niche { niche_variants, .. } => { if !niche_variants.contains(index) { size += tag.size(); } } } struct_tree = struct_tree.then(Self::from_tag(*tag, cx.tcx)); </ins> } // Append the fields, in memory order, to the layout.

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'Size::sub: 0 - 1 would result in negative size'', 'thread 'rustc' panicked at 'Size::sub: 0 - 1 would result in negative size'' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [evaluateobligation] evaluating trait selection obligation [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
On it! Thanks for the report.
Further minimized:
The cause here is neat. here is niche optimizable, with its second variant being subject to niche optimization. Typically, a niche-optimized enum has one tagless variant, and zero or more tagged variants laid out in the usual manner: the tag is placed, and then the rest of the fields follow. But reveals that's not what happens here. Because is a ZST, is placed at offset , rather than (following the tag). In other words: the tag is co-located with the field. This produces an ICE, because our assumption that fields follow tag is violated (a checked sub panics).
claim
Change:
--> $DIR/anon-params-denied-2018.rs:6:15 | LL |     fn foo(i32); //~ expected one of `:` or `@`, found `)` <del> |               ^ expected one of `:` or `@` here </del> <ins> |            ---^ expected one of `:` or `@` here |            | |            help: explicitly ignore parameter: `_: i32` | = note: anonymous parameters are removed in the 2018 edition (see RFC 1685) </ins> error: expected one of `:` or `@`, found `,` --> $DIR/anon-params-denied-2018.rs:8:36 | LL |     fn bar_with_default_impl(String, String) {} <del> |                                    ^ expected one of `:` or `@` here </del> <ins> |                              ------^ expected one of `:` or `@` here |                              | |                              help: explicitly ignore parameter: `_: String` | = note: anonymous parameters are removed in the 2018 edition (see RFC 1685) </ins> error: aborting due to 2 previous errors

Discussion:
This code works correctly on nightly and stable but not on 2018 edition, where it returns the error Changing it to solves it. Is this an intended change? I couldn't find anything about it in the edition guide.
Yes, this was done in
So apparently it was part of . In that case we should at least fix the error message, since it doesn't explain the source of the error at all.
Change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // compile-flags: -g use std::ops::Deref; trait Foo { fn foo() {} } impl Foo for u8 {} fn bar<T: Deref>() where T::Target: Foo { <<T as Deref>::Target as Foo>::foo() } fn main() { bar::<&u8>(); } </ins>

Discussion:
When trying to compile nphysics on a nightly created on or after , the compiler errors. Before this date it is fine. Example code: Presumably was that broke things, as it's a commit on that day that touches trans. On Windows 64 bit GNU this is the output:
cc
You sure it's that innocent commit and not, you know, my changes to debuginfo, for MIR? Specifically, is gone, that could cause problems.
I can't reproduce on master (just rebased one of my branches containing unrelated changes, so I had a compiler to check with). EDIT: Still no reproduction, even after .
Ok so I was misinterpreting which crate was being compiled. nphysics compiles fine, but , which uses nphysics, doesn't. I'm trying to narrow down the code now.
Here's some of the rust log that I got when compiling on debug builds:
That's not really helpful, sadly, nightly doesn't use yet, so there's no output.
This bug is not in beta, correct?
I'm afraid that I can't test that as I'm using s.
Can you check the test from instead? Particularly interested about the nightlies you had issues with.
Sure, unfortunately that test case works fine for both pre and post-.
Ah, beats me then.
I'll try and find which part of my code hits the error.
So I did some digging and I was wrong again, it turns out it is the nphysics crate. This is a minimal test case:
It depends on the crate, but it's not the crate itself, and that testcase is still large in terms of how much it needs to monomorphize.
True, sorry but I am not knowledgeable at all in rustc or nphysics, so it's the best I can do :/
triage: P-high
Still need a good regression test.
triage: P-low
I'm going to go ahead and close this. It's somewhat unlikely we'll hit this again (at least, we haven't obviously done so in the past 3ish years), and coming up with a good test case when the current case is all of nphysics is likely to be quite hard.
Change:
// The separator matches the current token. Advance past it. mp.idx += 1; self.next_mps.push(mp); <ins> } else { track.set_expected_token(separator); </ins> } } &MatcherLoc::SequenceKleeneOpAfterSep { idx_first } => {

Discussion:
one of the desired output should be much help, rather than: No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
// CHECK: ret i32 2 _bool(b) } <ins> #[inline] pub fn _iref(a: &u8) -> i32 { if unsafe { is_val_statically_known(a) } { 5 } else { 4 } } // CHECK-LABEL: @_iref_borrow( #[no_mangle] pub fn _iref_borrow() -> i32 { // CHECK: ret i32 4 _iref(&0) } // CHECK-LABEL: @_iref_arg( #[no_mangle] pub fn _iref_arg(a: &u8) -> i32 { // CHECK: ret i32 4 _iref(a) } #[inline] pub fn _slice_ref(a: &[u8]) -> i32 { if unsafe { is_val_statically_known(a) } { 7 } else { 6 } } // CHECK-LABEL: @_slice_ref_borrow( #[no_mangle] pub fn _slice_ref_borrow() -> i32 { // CHECK: ret i32 6 _slice_ref(&[0;3]) } // CHECK-LABEL: @_slice_ref_arg( #[no_mangle] pub fn _slice_ref_arg(a: &[u8]) -> i32 { // CHECK: ret i32 6 _slice_ref(a) } </ins>

Discussion:
Code 2 Few ICEs with new intrinsic <!-- 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. --: <details<summary<strongBacktrace 1</strong</summary<p</p</details<details<summary<strongBacktrace 2</strong</summary<p</p, so cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
like the intrinsic wasn't to the list at 2 Appears to be the same crash, just panicking at different points. label +F-core_intrinsics -needs-triage
claim
Would that check if the pointer address is constant or the referenced value is constant? I think for , one would expect the reference to be coerced to a . I don't know what to do for slices though.
I think checks for whether or not the the pointer address is statically known. I don't think mutable variables in function bodies can be statically known and references to globals are guaranteed to fold to false. That covers all the cases I thought about but I'm fairly confident I missed something.
They can be. It is usually the result of inlineing. Detecting that is kind of the point of the intrinsic.
Change:
enum IsInFollow { Yes, <del> No(Vec<&'static str>), </del> <ins> No(&'static [&'static str]), </ins> Invalid(String, &'static str), }

Discussion:
E.g. in a vec is created, only to be thrown away if the macro actually works out. I think we can just turn most places into an early return in the happy path and then only allocate in the error path. Do not work on this issue before is merged. Also, hasn't had its docs updated to reflect the source changes.
Are there any reasons to not use constant/static slices and convert them to vecs on demand? Or maybe even convert to something like so there's no need to allocate vecs (In all cases) anymore?
That's a great idea! I haven't checked whether it'll work everywhere, but I think it should.
Change:
<ins> fn main() { if true { "" //~ ERROR mismatched types [E0308] } } </ins>

Discussion:
When the is not the tail expression, we provide the right output. We might just have to change the order of operation when looking for additional context to print. as tail expression has the same problem. All checked, current version 1.78. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
why we don't suggest add in this case:
I believe it is because we check whether the tail expression is not a value. is never useful and people would never want it for any reason. For .
Hi, I'm new to the rust development and want to start with this issue.
you can make a comment saying to be assigned to the issue :) (so people filtering for unassigned issues to work on don't have it show up)
claim
I tried to investigate on this issue and here is a case that has the correct output: The difference between the two cases lies in: The correct case is parsed into nodes that include a node where the field is None. In contrast, in the erroneous case, the field of the node is not None, which is the content of filed in the of the correct case. More details are available in this gist: So the wrong case keeps iterating until node is the , which leads to the return here: The correct case has a early return with None here: Finally, in the function , the wrong case enters into the if condition unlike the other one: I'm uncertain about where to start with a fix. Should I modify the structure of this node or introduce some limitations? I've drafted a potential fix here: , but it's tailored specifically to this case. I'd appreciate any thoughts or feedback. Thanks!
I believe you can just modify to additionally check whether the node is an else-less (adding an arm to the match like ) with no adverse effects, but you'll have to try it out to see if there's any covered use of that expects that case to continue climbing the hir tree. Just run and that will modify the files to see the effects of your change. The other case: I think is ok. It could do with a more targeted error that will be more involved (to emit a single error instead of multiple), but I wouldn't consider it in scope for this ticket.

Thanks for you kind and clear instructions! I've ran and it turned out that this change has no effect on the other cases. Considering the other case you mentioned, in my opinion, I think it may be better to emit multiple errors. Here is a case: In this case, would aggregating errors into a single message make the correction less clear? I think the multiple errors might be a good reminder for users to fix errors in several specific branches. Maybe I misunderstand your meaning about the single error. Sorry for that.
Yeah, you're right. The only case where emitting a single E0308 error for this is when the expected type of the whole expression is one and all of the arms are of the same type.
Change:
<ins> // no-system-llvm // compile-flags: -O // ignore-debug: the debug assertions get in the way #![crate_type = "lib"] /// Make sure no bounds checks are emitted after a `get_unchecked`. // CHECK-LABEL: @unchecked_slice_no_bounds_check #[no_mangle] pub unsafe fn unchecked_slice_no_bounds_check(s: &[u8]) -> u8 { let a = *s.get_unchecked(1); // CHECK-NOT: panic_bounds_check a + s[0] } </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: Compile with on () I expected to see this happen: Both functions should compile to approximately the same thing, with no bounds check on the since the optimizer should be able to see that the slice is at least of length 2 due to the previous unchecked indexing. Instead, this happened: contains a bounds check (only does not contain a bounds check). rustc stable (1.73.0), nightly (2023-10-17), and 1.58.0 (when was stabilized) all have approximately the same codegen. : (no backtrace) label +C-optimization -C-bug
contains an assume intrinsic, doesn't. Might be worth adding it to the latter and see how that impacts perf, it's not guaranteed that it would actually improve things since we'd be emitting more IR and llvm would have to work harder. Commonly it's the case that if one uses one does so for all accesses on the slice, so this seems like an unusual pattern.
Change:
#![feature(crate_visibility_modifier)] #![feature(in_band_lifetimes)] #![feature(nll)] <ins> #![feature(or_patterns)] </ins> #![feature(try_blocks)] #![feature(never_type)] #![feature(slice_partition_dedup)]

Discussion:
<!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
managed to reduce the test case a bit.
Also happens for this code using a function instead of an associated type:
claim
initial example fixed by , associated function fixed by instead
Change:
} } } <ins> #[test] fn fmt_debug_select() { let sel = Select::new(); assert_eq!(format!("{:?}", sel), "Select { .. }"); } #[test] fn fmt_debug_handle() { let (_, rx) = channel::<i32>(); let sel = Select::new(); let mut handle = sel.handle(&rx); assert_eq!(format!("{:?}", handle), "Handle { .. }"); } </ins> }

Discussion:
All public types should implement Debug. Per conversation on #rust-internals, there might be some useful information that could be printed for these types -- but even just "Sender { .. }" etc. would be a start.
Was this
probably. It has been suggested that way more useful info could actually be printed instead of the opaque placeholders -- but that would be more of a wishlist item than a bug... The patch is sufficient to fix the actual problem I was running into: not being able to #[derive(Debug)] on any structure containing mpsc Senders/Receivers.
Ok, closing.
Change:
<ins> error[E0277]: the trait bound `(): _A` is not satisfied --> $DIR/issue-66353.rs:12:14 | LL |     _Func::< <() as _A>::AssocT >::func(()); |              ^^^^^^^^^^^^^^^^^^ the trait `_A` is not implemented for `()` error[E0277]: the trait bound `(): _Func<_>` is not satisfied --> $DIR/issue-66353.rs:12:41 | LL |     fn func(_: Self); |     ----------------- required by `_Func::func` ... LL |     _Func::< <() as _A>::AssocT >::func(()); |                                         ^^ the trait `_Func<_>` is not implemented for `()` error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
When using zipped iterators in a certain section of code, I hit an ICE. I've attached the project source -- sorry I could not produce a minimum example though I tried. Also, it's closed source, though I own it so can choose to provide the snapshot. Symptoms: Normally using zipped iterators doesn't cause an ICE, but in this case it is consistent (clean build, using , and ). Not zipping the iterators, and using prevents the ICE from occurring. This code fails to compile: This code compiles: Compilation error message: : 1.39 (stable): 1.40 (nightly): Backtrace: <details<summary1.39 stable</summary</details<details<summary1.40 nightly</summary</detailsInvestigation: Steps to reproduce: and run Relevant source file: Interestingly, using on the iterator on the ICE-ing code allows it to compile: Also interestingly, using the version within without also causes the ICE, so it's not the zipping that's causing it, but rather something to do with the being a reference rather than an owned value.
Seems to be an issue with Crash on stable, beta, nightly
regression from stable-to-stable 38.0 "worked"
A reduction would be good :)
I'm on it.
You want a MCVE? I give you a MCVE! modify labels: -E-needs-mcve +E-needs-bisection
Reduced:
regression between ...
cc
is the one to blame .
triage: P-high. Removing nomination label.
Change:
} } <ins> // Check that every lint from the list of attributes satisfies `f`. // Return true if that's the case. Otherwise return false. </ins> pub fn each_lint(sess: session::Session, attrs: &[ast::Attribute], f: |@ast::MetaItem, level, @str| -> bool)

Discussion:
Currently if you have some dead_code and you want to preserve it, you have to annotate every function you want to preserve and all the dead code that function calls. I think we should consider annotated code to be alive, and then all the code that touches to be alive as well.
cc sounds like a cool idea to me.
By "annotate", do you mean putting an attribute above the function you want to preserve?
yes.