jiebi/CodeConvo huggingface dataset:
Change:
} // Resolve any lifetime variables that may have been introduced during normalization. let Ok((trait_bounds, impl_bounds)) = infcx.fully_resolve((trait_bounds, impl_bounds)) else { <del> // This code path is not reached in any tests, but may be reachable. If // this is triggered, it should be converted to `delayed_bug` and the // triggering case turned into a test. tcx.dcx().bug("encountered errors when checking RPITIT refinement (resolution)"); </del> <ins> // If resolution didn't fully complete, we cannot continue checking RPITIT refinement, and // delay a bug as the original code contains load-bearing errors. tcx.dcx().delayed_bug("encountered errors when checking RPITIT refinement (resolution)"); return; </ins> }; // For quicker lookup, use an `IndexSet` (we don't use one earlier because

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. --(hand-reduced) <details<summary<strong(original)</strong</summary<p</p</details<!-- 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. --: Command: I put the option to remove "async fn" error, but I guess it is not an essential option to trigger ICE. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details- ICE location: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
searched nightlies: from nightly-2022-02-19 to nightly-2024-06-19 regressed nightly: nightly-2024-03-08 searched commit range: regressed commit: ()
Change:
}, BuiltinLintDiagnostics::NamedArgumentUsedPositionally(positional_arg, named_arg, name) => { db.span_label(named_arg, "this named argument is only referred to by position in formatting string"); <del> let msg = format!("this formatting argument uses named argument `{}` by position", name); db.span_label(positional_arg, msg); db.span_suggestion_verbose( positional_arg, "use the named argument by name to avoid ambiguity", format!("{{{}}}", name), Applicability::MaybeIncorrect, ); </del> <ins> if let Some(positional_arg) = positional_arg { let msg = format!("this formatting argument uses named argument `{}` by position", name); db.span_label(positional_arg, msg); db.span_suggestion_verbose( positional_arg, "use the named argument by name to avoid ambiguity", format!("{{{}}}", name), Applicability::MaybeIncorrect, ); } </ins> } } // Rewrap `db`, and pass control to the user.

Discussion:
Running clippy or build on the Vaultwarden code-base using breaks. It is broken since and still works on Tried to run before running this without luck. If you need any more information, please let me know. Vaultwarden: Working: Broken since: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Looks like this is a duplicate of , , , , , and Sorry for the clutter ;)

<!-- 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. --Upon running , the compiler panics when having as a dependency. and complete without error. Probably this is related to ? <!-- 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. --: and : : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p: </p</details
Appears to be a duplicate of
Change:
<ins> // This is not autofixable because we give extra suggestions to end the first expression with `;`. fn foo(a: Option<u32>, b: Option<u32>) -> bool { if let Some(x) = a { true } else { false } //~^ ERROR mismatched types //~| ERROR mismatched types && //~ ERROR mismatched types if let Some(y) = a { true } else { false } } fn main() {} </ins>

Discussion:
This example : (The example above was reduced from one involving , found by This regression was likely introduced by , due to the definition of : That function lists all of the operators that can't start an expression, but only continue it. () is incorrectly included, as is parsed the same as at the start of an expression. cc
I've left some comments on (a partial fix for a regression that seems similar to this, but more specific), e.g.: As per , should've never returned for , preventing the regression.
Assigning as and removing .
Change:
use middle; use middle::cast; use middle::check_const; <del> use middle::const_eval::{self, ConstVal}; </del> <ins> use middle::const_eval::{self, ConstVal, ErrKind}; </ins> use middle::const_eval::EvalHint::UncheckedExprHint; use middle::def::{self, DefMap, ExportMap}; use middle::dependency_format;

Discussion:
The message "expected constant integer for repeat count, but unsupported constant expr" is a bit weird (ungrammatical?).
Change:
"obj", ] <del> # Curiously, LLVM 7.0 will segfault if compiled with opt-level=3 # See issue https://github.com/rust-lang/rust/issues/52378 [profile.release] opt-level = 2 [profile.bench] opt-level = 2 </del> # These options are controlled from our rustc wrapper script, so turn them off # here and have them controlled elsewhere. [profile.dev]

Discussion:
Stack trace: Examples:
In we build with LLVM assertions enabled, but there is no messages from the log, meaning the segfault is not caused by broken assertions.
When setting opt-level=3 I believe that also changes the C/C++ code's optimization level, so this may be a but in clang's O3 optimization passes as well (and may in theory be fixable by compiling C++ code with O2)
I inspected generated CMake files and LLVM is built with nowadays but Rust is still using . How can I see if reapplying works without possibly breaking CI?
mentions LLVM7.0. Rust recently . So is this still an issue?
Change:
/////////////////////////////////////////////////////////////////////////// // BasicBlockData and Terminator <ins> /// See [`BasicBlock`] for documentation on what basic blocks are at a high level. </ins> #[derive(Clone, Debug, TyEncodable, TyDecodable, HashStable, TypeFoldable)] pub struct BasicBlockData<'tcx> { /// List of statements in this block.

Discussion:
modify labels: A-mir T-doc C-enhancement E-easy <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I would be interested in doing this :) claim
Should this issue be on rustc-dev-guide?
I'm not sure if it's covered there, but I meant in terms of a doc comment on the struct.
Ok, take a look around https://rustc-dev- then. But you might want to discuss around Zulip what the convention is for doc-comments.
Hmm, I think most of the items in MIR have doc comments. I can ask on Zulip though.
Change:
let callee_attrs = self.tcx.codegen_fn_attrs(callsite.callee.def_id()); self.check_codegen_attributes(callsite, callee_attrs)?; self.check_mir_is_available(caller_body, &callsite.callee)?; <del> let callee_body = self.tcx.instance_mir(callsite.callee.def); </del> <ins> let callee_body = try_instance_mir(self.tcx, callsite.callee.def)?; </ins> self.check_mir_body(callsite, callee_body, callee_attrs)?; if !self.tcx.consider_optimizing(|| {

Discussion:
I found this ICE while compiling in release mode. : <details<summary<strongBacktrace</strong</summary<p</p</detailsbisect command: bisect result: Regression in
uuh cc
For repro:
You're right that this ICEs after my PR but not before, but this looks like an issue related to type system code or , not MIR inlining itself, so I don't think I can't help here.
Ah so it would have iced before if we had forced inlining before?
Yes, with enough application of this code should ICE before that PR. I couldn't tell you where to apply the attribute though, just squinting at the ICE message it looks like this is significant, though I don't know enough to track down where that closure is.
Is there some rustc flag I can use to force inlining of like ~ everything ~ for testing purposes? :eyes: edit: -Zinline-mir-threshold=0 or something like that? :D
You need to set both thresholds, and I don't think we have a magic value for "always", just use a big number. The defaults are 50 and 100 I think. Also just FYI there's also an inlining depth limit that's not configurable, but it shouldn't be relevant for this PR. But if you see unexpected missed inlinings even with passing those flags, that threshold might be why.
Oh, those flags won't help you before the PR in question, because functions without are simply not considered for inlining at all, no matter their size. Fixing this odd ignoring of size was the whole point of that PR. You can pass to lift that "must have " requirement, but of course that turns on other passes, but the check you're trying to dodge is an explicit check for the MIR opt level inside the Inline pass so... yeah just you might also hit other bugs. You could try turning off the passes that are enabled at mir-opt-level=3 but that would be messy.

The mir opt level is cranked up already anyway Maybe I can find some snippet that somehow reassembles what we are seeing here :) I'll be able to report back in an hour or so I guess ^^
Meh besides a couple more "hangs" (process timeouts) nothing new in the standard rustc test set :/
This is a dupe of I believe
Another reproducer (possibly large): Run in , with rustc 1.71.0-nightly ( 2023-04-29) running on x86_64-unknown-linux-gnu. Failing CI log:
I've been getting this too since about a month ago: I can do a bisect.
Change:
<ins> #![feature(inherent_associated_types)] #![allow(incomplete_features)] mod m { pub struct T; impl T { type P = (); } } type U = m::T::P; //~ ERROR associated type `P` is private mod n { pub mod n { pub struct T; impl T { pub(super) type P = bool; } } type U = n::T::P; } type V = n::n::T::P; //~ ERROR associated type `P` is private fn main() {} </ins>

Discussion:
In the following code, I can successfully refer to the private inherent associated type : I expected to see an error denying the access. If the associated item was a constant, this would indeed be the case: : label T-compiler requires-nightly A-associated-items A-visibility F-inherentassociatedtypes <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
} // Non-ZST uninhabited types are, nonetheless, uninhabited. <del> fn yawning_void() { </del> <ins> fn yawning_void_struct() { </ins> enum Void {} struct YawningVoid(Void, u128);

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' 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 -- label +F-transmutability <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
Ah, it's an uninhabited non-ZST!
claim
I guess that answers my ;)
Change:
} } <ins> pub trait Trait4<'a, T> { type Output: 'a; fn qux(&self, _: &T) -> Self::Output; } pub struct Type4; impl<'a, T, U> Trait4<'a, U> for T { type Output = &'a i32; fn qux(&self, _: &U) -> Self::Output { &0 } } </ins> pub fn foo1(a: &dyn Trait1) { a.foo(); // CHECK-LABEL: define{{.*}}4foo1{{.*}}!{{<unknown kind #36>|kcfi_type}} !{{[0-9]+}}

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 --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // compile-flags: -C no-prepopulate-passes #![crate_type="rlib"] #[allow(dead_code)] pub struct Foo<T> { foo: u64, bar: T, } // The store writing to bar.1 should have alignment 4. Not checking // other stores here, as the alignment will be platform-dependent. // CHECK: store i32 [[TMP1:%.+]], i32* [[TMP2:%.+]], align 4 #[no_mangle] pub fn test(x: (i32, i32)) -> Foo<(i32, i32)> { Foo { foo: 0, bar: x } } </ins>

Discussion:
reduced from num_cpus: built with yields cc `
What’s the target? Ah, never mind, I missed that its .
More minimal: Issue does not occur on stable (or 1.30.0 nightly), but occurs on rustc beta.
Marking T-libs as that is likely to be an issue within implementation of , but I didn’t investigate further.
Excerpt: Clearly both of those adjacent i32 aren't going to be 8-byte aligned ^^ It seems that we're storing to an key with wrong alignment for some reason.
Don't need to look particularly far, this code generates It looks like some code is assuming that both elements in a scalar pair have the same alignment as the whole pair.
Probably the easiest way to get to the root cause is to bisect.
This code is very likely the culprit: It takes the 0 and 1 GEPs, but uses the same alignment, without offset adjustment.
Ouch, that's bad. To obtain the alignment for both fields, we need to do: Note that we can't use because the components do not match fields (the latter come from the user type definitions, whereas the former are extracted as an optimization).
Change:
} fn visit_item_kind(&mut self, item: &mut ast::ItemKind) { <del> match item { ast::ItemKind::MacroDef(..) => {} _ => { self.cfg.configure_item_kind(item); noop_visit_item_kind(item, self); } } </del> <ins> self.cfg.configure_item_kind(item); noop_visit_item_kind(item, self); </ins> } fn flat_map_generic_param(

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. --Found an ICE with when trying to use it in the standard library (). cc . <!-- 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 hit an additional ICE by using an unknown attribute instead of a valid one: <details<summary<strongBacktrace</strong</summary<p</p</detailsI don't really think it's useful for this issue though, since it's a delayed error.
Fixed in
Change:
use rustc_span::symbol::sym; use rustc_span::{DUMMY_SP, Symbol}; use rustc_target::abi::FIRST_VARIANT; <ins> use rustc_trait_selection::infer::at::ToTrace; use rustc_trait_selection::infer::{BoundRegionConversionTime, TyCtxtInferExt}; use rustc_trait_selection::traits::{ObligationCause, ObligationCtxt}; </ins> use tracing::{debug, info}; use crate::assert_module_sources::CguReuse;

Discussion:
I believe this is caused by . Does that look like anything to you? This doesn't seem to happen with the dist artifacts, only the settings used when testing in CI. The config used in CI is: EDIT: Almost certainly since it comes from . This is causing the reference test suite to fail. Using which is currently unreleased.
Yeah, it's a debug assertion after all. I'll look into it and relax the assertion
Change:
<del> error[E0401]: can't use generic parameters from outer function --> $DIR/self-ctor-inner-const.rs:7:27 | LL |         const C: S0<u8> = Self(0); |                           ^^^^ |                           | |                           use of generic parameter from outer function |                           can't use `Self` here error[E0401]: can't use generic parameters from outer function --> $DIR/self-ctor-inner-const.rs:9:21 | LL | impl<T> S0<T> { | ---- `Self` type implicitly declared here, by this `impl` ... LL |         fn bar() -> Self { |                     ^^^^ |                     | |                     use of generic parameter from outer function |                     use a type here instead error[E0401]: can't use generic parameters from outer function --> $DIR/self-ctor-inner-const.rs:11:13 | LL |             Self(0) |             ^^^^ |             | |             use of generic parameter from outer function |             can't use `Self` here error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0401`. </del>

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 made a blank cargo project (ran in an empty directory), and dependencies to my like so: Originally when I went to run , I was in nightly, and got a compile error (full error below). Then, when i switched to stable, there was no error and everything built fine! <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: Rust 1.69 <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged -- modify labels: +regression-from-stable-to-nightly -regression-untriaged
searched nightlies: from nightly-2023-02-15 to nightly-2023-05-13 regressed nightly: nightly-2023-05-05 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsrollup it didn't want to bisect the perf builds for some reason but i guess or could be at fault? haven't looked into the actual issue in detail, since it's behind a macro you probably know something about this anyways even if it may not be your fault
its not that is genericconstexprs only code
WG-prioritization assigning priority (). label -I-prioritize +P-high +T-compiler
Change:
use rustc_middle::{bug, span_bug}; use rustc_span::symbol::{kw, sym, Ident, Symbol}; use rustc_span::{Span, DUMMY_SP}; <del> use rustc_target::abi::FieldIdx; </del> use rustc_target::spec::abi; use rustc_trait_selection::error_reporting::traits::suggestions::NextTypeParamName; use rustc_trait_selection::infer::InferCtxtExt;

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'forcing query with already existing '', 'thread 'rustc' panicked at 'forcing query with already existing '' 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [findfield] find the index of maybe nested field in [typeck] type-checking [analysis] running analysis passes on this crate --
This bisects to :thinking:
WG-prioritization assigning priority (). cc: + for label -I-prioritize +P-medium
I'm going to fix it in (still WIP), where the query will be removed.
Testing out on this issue:
I seems like does not have proper or impls, possibly due to the differing . Are you familiar with that part of spans?
Change:
impl m::Pub for S {} fn g<T: m::Pub>(arg: T) { <del> arg.f(); //~ ERROR: source trait is private </del> <ins> arg.f(); //~ ERROR: source trait `m::Priv` is private </ins> } fn main() {

Discussion:
This was working previously before . If this is an intended change, we should probably give the error where the re-export is defined and not on use of the trait.
I've noticed this too while compiling nphysics, I've narrowed it to The error is I'm using .
I'm facing the same problem for quite some time now (currently rustc 1.0.0-nightly ( 2015-01-20 23:03:09 +0000)). Is this a bug or is it intended behavior?
is this expected?
Just ran into this bug in my code, would love to see a fix for this!
Im also still running into this from time to time (rustc 1.3.0). I'd love to see it fixed or clarified whether this is intended or a bug.
I also have this with rustc nightly (from PPA: "~~wily")
I think this is a bug, actually. do you agree?
yes I realize I'm responding to a comment from Jan 28 :) a bit late, I know
this was "fixed" by but reverted by due to a regression. Personally, I think that the correct fix for the regression should be to make a privacy error, but as far as I can tell, it's not easy to implement this currently, and it's likely to cause further regressions. Trait privacy is hard :(
better late than never :heart:
yeah this looks like a bug to me, and I think is right in that is probably the right fix if we deal with , which I think is the cause of some other visibility/privacy bug around here...
This can be simplified even further to: Also an additional note, this only affects usage in the same crate. Other crates are able to use the re-exports fine.
Still a bug in 1.6 :cry:
+1
still a bug in cargo 0.8.0-nightly ( 2016-01-17)
For those who may fall on this issue, it can be bypassed by using the UFCS syntax: . For example becomes
Change:
<ins> warning: the feature `type_alias_impl_trait` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/issue-78450.rs:4:12 | LL | #![feature(type_alias_impl_trait)] |            ^^^^^^^^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default = note: see issue #63063 <https://github.com/rust-lang/rust/issues/63063> for more information warning: 1 warning emitted </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. --Minimized: also occurs for but not <!-- 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. --: also on Rust Playground <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Somehow I missed that this does not require async. Also crashes with and returning .
minimized:
-- the minimization no longer ICEs for me
-- this sure looks like a dup of
After a discussion with Niko about this and assigning to myself we saw that there's already a PR. Unassigning myself then :).