jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0261]: use of undeclared lifetime name `'unpinned` --> $DIR/ice-cast-type-with-error-124848.rs:7:32 | LL | struct MyType<'a>(Cell<Option<&'unpinned mut MyType<'a>>>, Pin); |               -                ^^^^^^^^^ undeclared lifetime |               | |               help: consider introducing lifetime `'unpinned` here: `'unpinned,` error[E0261]: use of undeclared lifetime name `'a` --> $DIR/ice-cast-type-with-error-124848.rs:14:53 | LL | fn main() { |        - help: consider introducing lifetime `'a` here: `<'a>` ... LL |     let bad_addr = &unpinned as *const Cell<Option<&'a mut MyType<'a>>> as usize; |                                                     ^^ undeclared lifetime error[E0261]: use of undeclared lifetime name `'a` --> $DIR/ice-cast-type-with-error-124848.rs:14:67 | LL | fn main() { |        - help: consider introducing lifetime `'a` here: `<'a>` ... LL |     let bad_addr = &unpinned as *const Cell<Option<&'a mut MyType<'a>>> as usize; |                                                                   ^^ undeclared lifetime error[E0412]: cannot find type `Pin` in this scope --> $DIR/ice-cast-type-with-error-124848.rs:7:60 | LL | struct MyType<'a>(Cell<Option<&'unpinned mut MyType<'a>>>, Pin); |                                                            ^^^ not found in this scope | help: consider importing this struct | LL + use std::pin::Pin; | error[E0061]: this struct takes 2 arguments but 1 argument was supplied --> $DIR/ice-cast-type-with-error-124848.rs:12:24 | LL |     let mut unpinned = MyType(Cell::new(None)); |                        ^^^^^^----------------- an argument is missing | note: tuple struct defined here --> $DIR/ice-cast-type-with-error-124848.rs:7:8 | LL | struct MyType<'a>(Cell<Option<&'unpinned mut MyType<'a>>>, Pin); |        ^^^^^^ help: provide the argument | LL |     let mut unpinned = MyType(Cell::new(None), /* value */); |                              ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ error[E0606]: casting `&MyType<'_>` as `*const Cell<Option<&mut MyType<'_>>>` is invalid --> $DIR/ice-cast-type-with-error-124848.rs:14:20 | LL |     let bad_addr = &unpinned as *const Cell<Option<&'a mut MyType<'a>>> as usize; |                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to 6 previous errors Some errors have detailed explanations: E0061, E0261, E0412, E0606. For more information about an error, try `rustc --explain E0061`. </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: should be sized but is not?', 'error: internal compiler error: should be sized but is not?' File: --auto-reduced (treereduce-rust): original: Version 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: [typeck] type-checking [analysis] running analysis passes on this crate --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
this seems to bisect to fyi
claim
Change:
<ins> #![feature(type_alias_impl_trait)] type Closure = impl FnOnce(); //~ ERROR: type mismatch resolving fn c() -> Closure { || -> Closure { || () } } fn main() {} </ins>

Discussion:
This issue might be related to , which has been fixed in playground link: Backtrace:
removing the argument inside the closure gives a different ICE. Interestingly stable refuses to compile this, but beta and nightly ICE's playground: Backtrace:
UPDATE: now also ICE's in stable.
Now no longer ICE's since 1.32.
The ICE doesn't appear on the latest nightly via the above playground link, marked as E-needstest
Change:
<ins> #![feature(type_alias_impl_trait)] type Closure = impl FnOnce(); //~ ERROR: type mismatch resolving fn c() -> Closure { || -> Closure { || () } } fn main() {} </ins>

Discussion:
While minimizing I stumbled upon another ICE () Errors:
modify labels: I-ICE A-closures A-impl-trait C-bug F-typealiasimpl_trait T-compiler
The ICE doesn't appear on the latest nightly
Change:
fn default() -> Self { Providers { $($name: |_, key| bug!( <del> "`tcx.{}({:?})` unsupported by its crate", stringify!($name), key </del> <ins> "`tcx.{}({:?})` unsupported by its crate;  perhaps the `{}` query was never assigned a provider function", stringify!($name), key, stringify!($name), </ins> ),)* } }

Discussion:
I inadvertently deleted a assignment (which meant that any would not be resolved. Since query functions are assigned at runtime, this is not a build-time error. The best that can do is generate a runtime error, but the error message is non-intuitive, and it took quite a while for me to realize my mistake: Is there a better way to word this message to make it more obvious that there is a defined, but a provider was never assigned?
Maybe something like "no provider available for local/external crate" (depending on whether it's local or not)?
I think the reference to "crate" is what threw me off actually. To me, it implies the missing provider is missing in the code being compiled, but the problem was the provider should have been assigned in the compiler code itself.
The distinction matters though - there can be a provider for local crates but not external ones, or vice versa.
That's fine. I don't fully understand the significance of the crate, but if it helps others debug certain types of issues, it's fine to replace "unsupported by its crate" to "no provider available for local/external crate" (if the information is available). But the problem I had didn't have anything to do with the crate distinction, or at least, if it did, the message wouldn't have helped me diagnose the actual problem: In my case, there was a defined in for , and there should have been a assigned to that query, defined in the compiler code, in (except I mistakenly removed that query's assignment to . Removing that query assignment was a bug in the compiler code itself, regardless of what was happening with local vs. external crates. So how about just adding to either the current message or your revised message? I'm not sure how to tell what is local or external here, from just the or the , but I a placeholder. (AFAIK, the type is not necessarily a at this point.):
That looks good! Could you make a pr with that change? :)
- Happy to submit a PR, but I don't think exists. Is there a method that will give me something equivalent? If not, I can just use the original message, and add the to the end of it.
It's the other way around - there's only ever one , but may be local or non-local.

You could add an field to , and set it in
Hmm, that actually won't work because you have to have a function pointer, not a closure - you don't have access to the current state of the struct. Using the original message seems ok; I don't know if there's a better way.
OK, will do then. Thanks!
Change:
LL |  #![l=|x|[b;x ]] |     ^ <del> error[E0435]: attempt to use a non-constant value in a constant --> $DIR/issue-90878-2.rs:1:13 | LL |  #![l=|x|[b;x ]] |        -    ^ |        | |        this would need to be a `const` error[E0425]: cannot find value `b` in this scope --> $DIR/issue-90878-2.rs:1:11 | LL |  #![l=|x|[b;x ]] |           ^ help: a local variable with a similar name exists: `x` error: aborting due to 4 previous errors </del> <ins> error: aborting due to 2 previous errors </ins> <del> Some errors have detailed explanations: E0425, E0435. For more information about an error, try `rustc --explain E0425`. </del>

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting a few other errors, because the code is nonsense, so low priority. Affected versions: I tried nightly 2021-11-12 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</detailsAlso note how there is one additional error below the backtrace, not sure if that's expected.
Thanks for the bug report, could this be related to the recent HIR map/lowering refactorings?
This issue looks very similar to , but the examples from there don't panic anymore.

<!-- 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 got a very large poc file, and reduce it into following code. But after reducing (via a simple delta debugging tech), the code looks kind of confusing. Please let me know if anyone prefers a better-formed but long test-case, and I will try me best to get one. md5: <!-- 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. --The bug is reproduced with nightly and beta versions, but not with stable version. : 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
This can be "solved" by using and create a instead of panicking.
Assigning as discussed as part of the and removing .
A reproduction with fewer errors:
The provided examples do not panic anymore, can this issue be closed or does it need tests?
lets keep it open purely to track adding regression tests for these.
Change:
<ins> //@ build-pass //@ compile-flags: -Zmir-opt-level=3 --emit=mir fn hey<T>(it: &[T]) where [T]: Clone, { } fn main() {} </ins>

Discussion:
File: season two auto-reduced (treereduce-rust): original: Version 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
cc
I cannot reproduce the original anymore, but does reproduce. The body is impossible because of the where clauses, so no MIR opts should ever run on it... I'll take a look.
I can still reproduce this with the original mvce when I use the flags that I listed.
bisected with searched nightlies: from nightly-2023-09-01 to nightly-2023-10-01 regressed nightly: nightly-2023-09-09 searched commit range: regressed commit: bisected with <a href=''cargo-bisect-rustc</av0.6.8 cc oli was right:
The bisection here isn't useful sadly, but thank you anyways. I took a look and yeah, the issue is what I suspected. () checks whether there are any impossible predicates (like here). It sadly has to filter out "non-global" predicates, which belongs to. It has to do this because of overflows as mentioned above. told me that the new trait solvers non-fatal handling of overflow will allow this to be fixed. But until then, there's nothing we can do. As for getting the code working, the solution here so to avoid these impossible bounds wherever possible. In the example here, that's easy to do, just delete it. In that's a bit more annoying, I don't really see a solution. We could try playing whack-a-mole by trying to make the MIR opts sorta-handle these cases that slip through, but I don't think that's very sustainable. Might work at least for the trivial cases like though, but I don't open PRs for that.
another one
I'm afraid that this has reached stable with 1.78. I couldn't reproduce it with the minimal example in the previous comment, but a crate of mine now fails on stable, but compiled fine on 1.77.2: <details<summaryfull output</summary</detailsThe code responsible for this is fairly simple: Removing that impl makes the crate compile again.

Will we still just wait for the new solver, now that it's a stable-stable regression?
I managed to minimize the example from : (, ICE in release mode)
Change:
pub unsafe fn init(&self) { let mut attr = MaybeUninit::<libc::pthread_mutexattr_t>::uninit(); <del> let result = libc::pthread_mutexattr_init(attr.as_mut_ptr()); debug_assert_eq!(result, 0); let result = libc::pthread_mutexattr_settype(attr.as_mut_ptr(), libc::PTHREAD_MUTEX_RECURSIVE); debug_assert_eq!(result, 0); let result = libc::pthread_mutex_init(self.inner.get(), attr.as_ptr()); debug_assert_eq!(result, 0); let result = libc::pthread_mutexattr_destroy(attr.as_mut_ptr()); debug_assert_eq!(result, 0); </del> <ins> cvt_nz(libc::pthread_mutexattr_init(attr.as_mut_ptr())).unwrap(); let attr = PthreadMutexAttr(&mut attr); cvt_nz(libc::pthread_mutexattr_settype(attr.0.as_mut_ptr(), libc::PTHREAD_MUTEX_RECURSIVE)) .unwrap(); cvt_nz(libc::pthread_mutex_init(self.inner.get(), attr.0.as_ptr())).unwrap(); </ins> } pub unsafe fn lock(&self) {

Discussion:
In libstd/sys/unix there are numerous cases where return code is checked for error using following pattern: That means, that error checking is performed only when compiled in non-optimized mode or after explicitly enabling debug assertions. This is a little bit worrying, especially when used on platforms where those functions can indeed fail and break safety.
(For anyone who was confused by the given example, pthreadmutexattrinit can fail with ENOMEM.)
On some platforms types like pthreadmutext, pthreadcondt, etc., are "fat" structures that have sufficient size to hold everything necessary and their initialization will never fail (unless initialized incorrectly). But on others they are opaque pointers to and require an additional memory allocation. Search for those typedefs in libc crate, gives a rough approximation of affected platforms. Sadly this also affects static mutexes, so even lock / unlock could potentially fail. Either way you could end up with a mutex which is not mutually exclusive at all.
When mutex initialization fails this leads to non-functioning mutex and unsoundness. The pthreadmutexlock might also fail for recursive mutexes used in std::io and cause a mismatch in the number of locks / unlocks, but one needs to go out of the way to cause that. modify labels: C-bug I-unsound
Change:
return Ok((res, Some(path_str.to_owned()))); } Res::Def(DefKind::Mod, _) => { <del> // This resolved to a module, but if we were passed `type@`, // we want primitive types to take precedence instead. if disambiguator == Some(Disambiguator::Namespace(Namespace::TypeNS)) { </del> <ins> // This resolved to a module, but we want primitive types to take precedence instead. if matches!( disambiguator, None | Some(Disambiguator::Namespace(Namespace::TypeNS)) ) { </ins> if let Some(prim) = is_primitive(path_str, ns) { if extra_fragment.is_some() { return Err(ErrorKind::AnchorFailure(AnchorFailure::Primitive));

Discussion:
For example in the doc for : The in the doc links to instead of . Outside of the standard library, links to the primitive, unless there is a statement in which case it links to the module.
Therefore we should try to link to types before modules I assume? I'll see how it comes out.
Yes I think types should go before modules. After all it's always possible to use charstd::charstd::charchar` as the link text.
Oh btw, you can force the resolution by adding the type before hand like . I wonder if this is documented somewhere... Just like you can say it's a macro by at the end or a function by adding at the end.
It comes from the compiler directly. We need to re-order how the items are resolved. cc
an alternative is to resolve in an empty module first and only then resolve in the current scope. This ambiguity is only possible for primitives, any other types will give a multiple definition error: Since primitives are always in scope they will be the only thing in scope in the empty module (assuming there's no , , or keyword).
Originally posted by in is this still your opinion? That would mean closing this issue as wontfix, but I'm not convinced that's the most clear behavior.
Well, I would close this as fixed, but yes. I think this is a pretty rare situation to be in and the current behavior is not incorrect, it's just surprising, but "fixing" it would also make it surprising to another group.
and I discussed this again and decided it would be less surprising than the current behavior ( himself made the same mistake in !) So I plan to implement this sometime soon.
Change:
<ins> // Copyright 2017 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. #![feature(unboxed_closures, fn_traits, rustc_attrs)] #[rustc_error] fn main() { //~ ERROR compilation successful let k = |x: i32| { x + 1 }; Fn::call(&k, (0,)); } </ins>

Discussion:
I was trying to compile the following code: And got the following compiler error: Version info:
Still ICEs.
Minimal:
Triage: tracked by glacier
No longer ICEs today. E-needstest. I'm somewhat concerned though because this is the second glacier-tracked ICE that I've seen "fixed."
This was only broken because of the old code.
Change:
// We may want to remove the namespace scope if we're in an extern block (see // https://github.com/rust-lang/rust/pull/46457#issuecomment-351750952). let var_scope = get_namespace_for_item(cx, def_id); <del> let span = tcx.def_span(def_id); </del> <ins> let span = hygiene::walk_chain_collapsed(tcx.def_span(def_id), DUMMY_SP); </ins> let (file_metadata, line_number) = if !span.is_dummy() { let loc = cx.lookup_debug_loc(span.lo());

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: then shows I'd expect DWATdecl_line to be 9 (the line where the macro is called), not 5 (the line where the static is defined inside the macro). <!-- 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. --:
cc
Change:
<ins> #![feature(rustc_attrs)] // edition:2021 // Test that any precise capture on a union is truncated because it's unsafe to do so. union Union { value: u64, } fn main() { let u = Union { value: 42 }; let c = #[rustc_capture_analysis] //~^ ERROR: attributes on expressions are experimental //~| NOTE: see issue #15701 <https://github.com/rust-lang/rust/issues/15701> || { //~^ ERROR: First Pass analysis includes: //~| ERROR: Min Capture analysis includes: unsafe { u.value } //~^ NOTE: Capturing u[(0, 0)] -> ImmBorrow //~| NOTE: Min Capture u[] -> ImmBorrow }; c(); } </ins>

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: no error Instead, this happened: rustc 1.55.0-nightly 2018 edition rustc 1.55.0-nightly 2021 edition <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
claim
Change:
<ins> // Regression test for #67739 #![allow(incomplete_features)] #![feature(const_generics)] use std::mem; pub trait Trait { type Associated: Sized; fn associated_size(&self) -> usize { [0u8; mem::size_of::<Self::Associated>()]; //~^ ERROR: array lengths can't depend on generic parameters 0 } } fn main() {} </ins>

Discussion:
: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'd like to work on this. claim
Now ICE no longer occurs, I think it's fixed by . Marked as E-needstest.

When executed in the : <details<summaryCompiler output</summary</detailsEDIT: Here's the updated and the new stack trace as of Jan 7, 2020: <details<summaryCompiler output</summary</details
cc
I think this is another instance of However, we can leave this issue open to remember to add a test case when it's fixed.
The original issue no longer ICEs and instead errors with: which is essentially correct. However, providing the type annotations produces a new ICE:
In Source: <details<summaryStack trace</summary<p</p</details
Now ICE no longer occurs. I think it's fixed by .

This occurs on 1.34.1 and 1.34.0, is a regression from 1.33.0, and does.. not occur on nightly? Reproduction: compiled with Yields: I found this in building crates like and but pared it down to this
I think this is fixed in which might explain why it doesn't occur on nightly
triage: Probably fixed by . Normally an ICE would lead me to tag this as P-high, but the fact that this is only exposed by leads me to prioritize this as P-medium.
assigning to self to confirm that is the reason this is fixed, and (if need be) add a regression test.
Here's a slightly smaller case of what appears to potentially be the same thing which shows up if you select the "show MIR" option in In particular the following error is observed:
I think this issue is fixed in all channels. I tried stable and nightly both locally and on , and couldn't get any ICEs. Should we add a test? Otherwise we can just close I think.
Adding a test with seems like a good idea.

Compiler crash when using cfgif and defining a macro with macrorules twice. I tried this code: In a repo: I expected to see this happen: error: a macro named has already been exported Instead, this happened: error: internal compiler error: unexpected panic : Backtrace:
Regression from stable to stable (works in 1.30). Reduced test case:
mode is implemented on best effort basis, generally unsupported and will be removed in some time.
Ah, I see, the original issue doesn't have it. I'll investigate.
Reproducer in no longer ICEs.
Change:
<ins> // Regression test for #67739 #![allow(incomplete_features)] #![feature(const_generics)] use std::mem; pub trait Trait { type Associated: Sized; fn associated_size(&self) -> usize { [0u8; mem::size_of::<Self::Associated>()]; //~^ ERROR: array lengths can't depend on generic parameters 0 } } fn main() {} </ins>

Discussion:
results in: Removing the constgenerics feature flag gets the expected error message: (IIUC that itself is a bug related to ) Using directly outside of a const-context works, which I guess is something const_generics enables that isn't otherwise allowed. Finally, the error message is the same whether or not the code is in a provided method or a impl block; I actually ran into the bug in the later.
I believe this should be fixed by
Now, it shows different ICE(s) ():
Now ICE no longer occurs. I think it's fixed by .
Change:
/// ``` #[inline] #[must_use] <del> #[unstable(feature = "cmp_min_max_by", issue = "64460")] </del> <ins> #[stable(feature = "cmp_min_max_by", since = "1.53.0")] </ins> pub fn min_by_key<T, F: FnMut(&T) -> K, K: Ord>(v1: T, v2: T, mut f: F) -> T { min_by(v1, v2, |v1, v2| f(v1).cmp(&f(v2))) }

Discussion:
Tracking issue for the feature, which adds the / / / functions to . PR:
Is there anything blocking this from stabilizing?
Doesn't look like it! If somebody would like to open a stabilization PR then we can start a FCP
Stabilization PR up at