jiebi/CodeConvo huggingface dataset:
Change:
self.demand_suptype(provided_arg.span, formal_input_ty, coerced_ty); }; <ins> let minimum_input_count = formal_input_tys.len(); </ins> // Check the arguments. // We do this in a pretty awful way: first we type-check any arguments // that are not closures, then we type-check the closures. This is so

Discussion:
If using format inside a closure (e.g. in iter functions) and the returning String is passed into a function that takes less args, rustc panics. Minimized code snippet: version: 1.60.0-beta.2 and 1.61.0-nightly query: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
playground link:
Probably duplicate of
Actually, not sure if it's a duplicate of . Still failing on master after the fix for that one landed, and failed with the same error (and not a duplicated adjustment bug) on beta. I will look into it! claim
Minimized:
Change:
<ins> // Strip out raw byte dumps to make comparison platform-independent: //@ normalize-stderr-test "(the raw bytes of the constant) (size: [0-9]*, align: [0-9]*)" -> "$1 (size: $$SIZE, align: $$ALIGN)" //@ normalize-stderr-test "([0-9a-f][0-9a-f] |╾─*A(LLOC)?[0-9]+(+[a-z0-9]+)?(<imm>)?─*╼ )+ *│.*" -> "HEX_DUMP" //@ normalize-stderr-test "HEX_DUMPs*ns*HEX_DUMP" -> "HEX_DUMP" pub struct Wrapper; pub static MAGIC_FFI_REF: &'static Wrapper = unsafe { //~^ERROR: it is undefined behavior to use this value std::mem::transmute(&{ let y = 42; y }) }; fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: could not find allocation for alloc3', 'error: internal compiler error: could not find allocation for alloc3' 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: [evalstaticinitializer] evaluating initializer of static [analysis] running analysis passes on this crate -- label +F-extern_types
Regression in nightly-2024-05-23 cc :thinking:
Anyway it doesn't seem to affect the test.
This is not a recent regression, here's a reproducer on stable:
But why?^^ lol XD its just side effect of the fuzzing I guess :D
Change:
(_, "volatile_load") => { let tp_ty = *substs.types.get(FnSpace, 0); let ptr = to_arg_ty_ptr(bcx, llargs[0], tp_ty); <del> from_arg_ty(bcx, VolatileLoad(bcx, ptr), tp_ty) </del> <ins> let load = VolatileLoad(bcx, ptr); unsafe { llvm::LLVMSetAlignment(load, type_of::align_of(ccx, tp_ty)); } from_arg_ty(bcx, load, tp_ty) </ins> }, (_, "volatile_store") => { let tp_ty = *substs.types.get(FnSpace, 0); let ptr = to_arg_ty_ptr(bcx, llargs[0], tp_ty); let val = to_arg_ty(bcx, llargs[1], tp_ty); <del> VolatileStore(bcx, val, ptr); </del> <ins> let store = VolatileStore(bcx, val, ptr); unsafe { llvm::LLVMSetAlignment(store, type_of::align_of(ccx, tp_ty)); } </ins> C_nil(ccx) },

Discussion:
The attached source produces code that misbehaves on some platforms that are picky about memory access alignment. The code should exit with code 2, but on both Emscripten-generated JavaScript and ARMv5, it finishes with exit code 1 to indicate that the field is incorrectly tested as equal to . Changing the field to a type results in proper execution on these platforms. All optimization levels seem to cause it. Libraries that make use of structs with fields followed by enums seem particularly prone to this problem. It all works fine on platforms that allow unaligned memory access like x86, ARMv6, etc. Expected output: (x86, ARMv6) Actual output: (ARMv5, Emscripten) Note that the same ARM binary runs on both ARMv5 and ARMv6 platforms, producing the different results. See also: ( and removed)
To quote myself:
Change:
} ExprKind::Cast { source } => { let source = this.hir.mirror(source); <del> if source.ty == expr.ty { this.expr_as_rvalue(block, source) } else { let source = unpack!(block = this.as_operand(block, source)); block.and(Rvalue::Cast(CastKind::Misc, source, expr.ty)) } </del> <ins> let source = unpack!(block = this.as_operand(block, source)); block.and(Rvalue::Cast(CastKind::Misc, source, expr.ty)) </ins> } ExprKind::ReifyFnPointer { source } => { let source = unpack!(block = this.as_operand(block, source));

Discussion:
Compiling the crate with on ARM Linux: or : This was my first contact with mir and it wasn't peaceful :) Maybe I should have tried a , erm instead...
More ICEy stuff: coming from crate.
Minimal reproduction: It's the that is the problem. What happens is that we first reify to a function pointer, then try to cast the function pointer itself. It seems that we don't expect an cast in the MIR. I'm pretty sure that is only valid when it's a no-op, so we can probably just handle it MIR translation. that seem correct?
I some code to not build noop casts, the lifetimes may be different here though?
possibly, doing first and using in the cast works, so I'd say that lifetimes are the most likely source of difference between the two types in the cast. Do we have a lifetime-ignoring comparison we could use in this case?
Problem is, you can't ignore lifetimes, what if this is a to cast? There might be another way to tell that a cast only triggered a coercion, at the HAIR level. EDIT: Well, actually, the good old is a reification coercion + ptr-to-int cast.
do you mind giving a backtrace for that second error and opening a new issue for it (since it's unrelated to the two in the main post). If you could reduce it to a smaller reproduction, that would be even better.
There were no backtraces, unfortunately. Let's clarify one thing though - is turning off for a single crate and then resuming the mir'ed build, ok? That's how I arrived at the latter issue. (edit: wasn't the problem)
Actually MIR compilation has been bootstrappable for the compiler for a while now, so trying to use it for more complex codebases is really valuable, since it finds bugs like this.
The compiler doesn't generate a backtrace even if you set ?
That was the case indeed. (both ended in a segfault) -original message- Subject: Re: From: Eduard-Mihai Burtescu Date: 01.05.2016 12:22 The compiler doesn't generate a backtrace even if you set ? You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub:
Yeah, that's why I tried it - that whole sentence was a big pun on the word mir. (meaning both peace and world)
Change:
} } ObligationCauseCode::VariableType(hir_id) => { <ins> if let Some(typeck_results) = &self.typeck_results && let Some(ty) = typeck_results.node_type_opt(hir_id) && let ty::Error(_) = ty.kind() { err.note(format!( "`{predicate}` isn't satisfied, but the type of this pattern is  `{{type error}}`", )); err.downgrade_to_delayed_bug(); } </ins> match tcx.parent_hir_node(hir_id) { Node::Local(hir::Local { ty: Some(ty), .. }) => { err.span_suggestion_verbose(

Discussion:
It's underlining the wrong argument. No response No response
I'm getting an entirely different and much more helpful error:
Are you sure you minimized the code correctly? Not sure how to repro the example you shared,
Arf, sorry about that... Also important to note, I'm using: I pushed the code with this issue . However it requires a mac to enter this code. Just running is enough to trigger it.
This should be re-minimized by someone who has a Mac then. label +E-needs-mcve
Minimization: Note that: in all cases (including when I ran the original code), there is now a more sensible type error, and the unsized local error is not actually pointing at the wrong thing, it's talking about the type of the part of the tuple unrelated to the if/else type mismatch. It seems like the type mismatch is causing the compiler to fail to properly perform the deref coercion of the , even though it's not the part of the tuple that has the type mismatch. Tested on versions:
label -E-needs-mcve
Change:
<ins> use std::path::Path; const FORBIDDEN_PATH: &str = "src/test"; const ALLOWED_PATH: &str = "tests"; pub fn check(root_path: impl AsRef<Path>, bad: &mut bool) { if root_path.as_ref().join(FORBIDDEN_PATH).exists() { tidy_error!( bad, "Tests have been moved, please move them from {} to {}", root_path.as_ref().join(FORBIDDEN_PATH).display(), root_path.as_ref().join(ALLOWED_PATH).display() ) } } </ins>

Discussion:
A PR modifying an existing test now has a merge conflict e.g. but a PR adding a new test doesn't e.g. , and I'm worried if a new test is to by accident. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Mentoring instructions: Add a new module to src/tools/tidy, then call the check from See the surrounding code for examples of how tidy checks work.
I am confused as to why this was not a blocker for moving the tests
"I didn't think of it"
claim
Change:
<ins> pub static V: &u32 = &X; pub static F: fn() = f; static X: u32 = 42; pub fn v() -> *const u32 { V } fn f() {} </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. --I couldn't I couldn't produce a single file example, as it seems the ICE is triggered when cross crate compilation is involved; i.e dumping the contents of into does not trigger the ICE. This seems like a regression of the feature as this previously worked on nightly of the 1.50 stable release. : : <!-- 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
While regression itself is related to the introduction of CTFE MIR, it seems this actually never worked correctly, with static ending up duplicated.
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
I can't reproduce with the latest nightly and cargo. Are there any further instructions for reproducing this?
Apologies, forgot to mention you'll need to add Or build for a target that does not have panic unwinding enabled by default.
(discussed in T-compiler meeting. This is an issue on stable, and might get a backport via . Re-opening to investigate details of what worked, what stopped working, what is fixed, and what is still broken.)
In the case reported here, one crate references static from another crate. During mono item collection, based on reachability determines whether it will link to item from an upstream crate or codegen it locally. When decision is made to codegen locally, it is followed by an assertion that optimized MIR is available to do so. In 1.50 static is non-reachable and codegenned locally. In 1.51 and 1.52 static is non-reachable, but the assertion fails since statics no longer use optimized MIR. In nightly, since , the static is reachable and linked to. The change seems safe for backporting to me.
Closing as the .
Change:
const F : C = C::D; assert_eq!(match C::D { F => 1, _ => 2, }, 1); <ins> // test gaps #[derive(PartialEq, Eq)] enum G { H = 3, I = 5 } const K : G = G::I; assert_eq!(match G::I { K => 1, _ => 2, }, 1); </ins> } fn issue_13731() {

Discussion:
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!
Change:
ty::PredicateKind::RegionOutlives(pred) => pred.clean(cx), ty::PredicateKind::TypeOutlives(pred) => pred.clean(cx), ty::PredicateKind::Projection(pred) => Some(pred.clean(cx)), <ins> ty::PredicateKind::ConstEvaluatable(..) => None, </ins> ty::PredicateKind::Subtype(..) | ty::PredicateKind::WellFormed(..) | ty::PredicateKind::ObjectSafe(..) | ty::PredicateKind::ClosureKind(..) <del> | ty::PredicateKind::ConstEvaluatable(..) </del> | ty::PredicateKind::ConstEquate(..) | ty::PredicateKind::TypeWellFormedFromEnv(..) => panic!("not user writable"), }

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. --: <details<summary<strongBacktrace</strong</summary<p</p</details
Related:
do you know what's going on here? The rustdoc code is
Yeah, that one's somewhat expected. adds predicates to , so we now have to deal with them in rustdoc, can fix this myself next week
I minimized the failure I'm seeing in rustdoc and it looks like it's this issue and not a separate one. Is there any workaround or is any expected to see this breakage w/rustdoc?
No, there's no workaround that I know of. I don't understand the implementation of const generics very well, nor does anyone else on the team.
Does anyone know what would be needed to fix this, or at least work around it enough to stop from crashing? (This is currently disabling for our project, which relies on some code.)
Change:
} // Get closure's arguments <del> let ty::Closure(_, substs) = typeck_results.expr_ty(closure_expr).kind() else { unreachable!() }; </del> <ins> let ty::Closure(_, substs) = typeck_results.expr_ty(closure_expr).kind() else { /* hir::Closure can be a generator too */ return }; </ins> let sig = substs.as_closure().sig(); let tupled_params = tcx.erase_late_bound_regions(sig.inputs().iter().next().unwrap().map_bound(|&b| b));

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
searched toolchains nightly-2023-04-20 through nightly-2023-04-28 Regression in nightly-2023-04-21 searched toolchains through Regression in :thinking: cc
Well, it is not unreachable it turns out huh
I believe this is a MRE:
Change:
} } <ins> pub fn combine_duplicate_switch_targets(terminator: &mut Terminator<'_>) { if let TerminatorKind::SwitchInt { targets, .. } = &mut terminator.kind { let otherwise = targets.otherwise(); if targets.iter().any(|t| t.1 == otherwise) { *targets = SwitchTargets::new( targets.iter().filter(|t| t.1 != otherwise), targets.otherwise(), ); } } } </ins> pub fn remove_duplicate_unreachable_blocks<'tcx>(tcx: TyCtxt<'tcx>, body: &mut Body<'tcx>) { struct OptApplier<'tcx> { tcx: TyCtxt<'tcx>,

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 branch instructions emitted, makes an assumption that is , so should be inlined and optimized as a panic. Instead, this happened: there is a discriminant check still emitted. <!-- Provide the most recent version this worked on, for example: It most recently worked on: --It most recently worked on: nightly-2023-03-26 <!-- Provide the version you are using that has the regression. --See godbolt: Regression occurred in (cc searched nightlies: from nightly-2023-03-01 to nightly-2023-04-01 regressed nightly: nightly-2023-03-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: aarch64-unknown-linux-gnu Reproduce with: </details<details</summary(if you want to test on replace with ) </details<details</summary</details originally noticed the problem and opened , then suggested that this is a compiler issue, then that this is a regression, then bisected and opened this issue.
The end of this regression window is over 2 weeks from now. Why? Godbolt usually has pretty old nightlies. If I add : you can see we have duplicate switch targets, which means that either this commit is broken or godbolt doesn't have it:
godbolt seems to have ?
Because I knew that reproduces the regression, and wanted to cut some time bisecting. For reference I can reproduce the same issue with . <details<summary+nightly-2023-04-19 --emit=mir</summary</details
To be clear, separate from this issue I believe that this MIR: is a bug. I do not know what impact resolving that would have on this issue. But the helper that combines switch targets was (notionally) supposed to prevent this.
Yeah, I'm pretty sure that is the root cause.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
} } <ins> pub fn report_partial_reinitialization_of_uninitialized_structure( &self, span: Span, lp: &LoanPath<'tcx>) { self.tcx .sess .span_err(span, (format!("partial reinitialization of uninitialized  structure `{}`", self.loan_path_to_string(lp))).as_slice()); } </ins> pub fn report_reassigned_immutable_variable(&self, span: Span, lp: &LoanPath<'tcx>,

Discussion:
So I was curious how Drop handles cycles, because this could lead to dangling pointers, which is why . And indeed the below example does not call Drop. But is moved into , so why does this compile at all?
Nominating, seems like a soundness hole.
This is an issue with zeroing dynamic drops (which are going to be removed: rust-lang/rfcs) – when is moved, its drop flag is cleared, which prevents the destructor of from running. A clearer example is:
Structs that implement drop are not supposed to be in a partially initialized state. We already prevents moves out from individual fields, but we also need to prevent individual fields from being re-initialized. cc since (iirc?) he was working on the patches that made us more accepting around re-initializing fields and so forth, and maybe this bug is of interest to him.
So we are not supposed to allow structs that implement drop to be partially initialized. We already disallow going from fully-initialized to partially initialized. But it seems (from the first example) that we missed disallowing going from fully-uninitialized to partially initializd. That needs to be fixed. Assigning P-backcompat-lang, 1.0.
While this will hopefully be fixed soon, as there is a PR up, it seems to have fallen through the cracks as a P-backcompat-lang issue that is only on the 1.0 milestone and not 1.0 beta. Nominating for 1.0 beta. (Also, I guess I will try to run through and find any other such overlooked issues.)
Assigning 1.0 beta.
Change:
if env is None: env = {} <ins> # This test ends up invoking build_bootstrap_cmd, which searches for # the Cargo binary and errors out if it cannot be found. This is not a # problem in most cases, but there is a scenario where it would cause # the test to fail. # # When a custom local Cargo is configured in config.toml (with the # build.cargo setting), no Cargo is downloaded to any location known by # bootstrap, and bootstrap relies on that setting to find it. # # In this test though we are not using the config.toml of the caller: # we are generating a blank one instead. If we don't set build.cargo in # it, the test will have no way to find Cargo, failing the test. cargo_bin = os.environ.get("BOOTSTRAP_TEST_CARGO_BIN") if cargo_bin is not None: configure_args += ["--set", "build.cargo=" + cargo_bin] rustc_bin = os.environ.get("BOOTSTRAP_TEST_RUSTC_BIN") if rustc_bin is not None: configure_args += ["--set", "build.rustc=" + rustc_bin] </ins> env = env.copy() env["PATH"] = os.environ["PATH"]

Discussion:
I tried this with Rust 1.66.0, simplified from my build for Fedora: I expected to see this happen: passing tests Instead, this happened: 20 failures, all of this sort: My stage0 should be using . It most recently worked on: Rust 1.65.0 : I bisected this to , commit , which stopped using and environment variables when building a . <details<summaryBacktrace</summary<p</p</details modify labels: +regression-from-stable-to-stable -regression-untriaged +A-bootstrap <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
FYI we had the same problem on Debian, worked around with a custom patch:
Change:
<ins> // run-pass #![feature(layout_for_ptr)] use std::mem; #[repr(packed(4))] struct Slice([u32]); #[repr(packed(2), C)] struct PackedSized { f: u8, d: [u32; 4], } #[repr(packed(2), C)] struct PackedUnsized { f: u8, d: Slice, } impl PackedSized { fn unsize(&self) -> &PackedUnsized { // We can't unsize via a generic type since then we get the error // that packed structs with unsized tail don't work if the tail // might need dropping. let len = 4usize; unsafe { mem::transmute((self, len)) } } } fn main() { unsafe { let p = PackedSized { f: 0, d: [1, 2, 3, 4] }; let p = p.unsize() as *const PackedUnsized; // Make sure the size computation correctly adds exact 1 byte of padding // in front of the `d` field. assert_eq!(mem::size_of_val_raw(p), 1 + 1 + 4*4); // And likewise for the offset computation. let d = std::ptr::addr_of!((*p).d); assert_eq!(d.cast::<u32>().read_unaligned(), 1); } } </ins>

Discussion:
This code panics, but it should not: The panic disappears when the is inlined (because then we hit a different code path in ). What happens here is a bug in the logic that computes the offset of : since it is an unsized field, the offset is computed dynamically, by taking the statically known offset and then rounding it up to the dynamic alignment of the field. However, since the struct is packed, we need to cap the dynamic alignment of the field to the packing of the surrounding struct -- which we currently do not do. This is just yet another case where the non-compositional nature of is causing issues...
A slight variant of this code ICEs: It hits which, it seems, was never updated when support for was implemented.
WG-prioritization assigning priority (). label -I-prioritize +P-medium EDIT: lowered priority after discussion on Zulip
Change:
// Use `||` to give these suggestions a precedence let _ = self.suggest_missing_parentheses(err, expr) <ins> || self.suggest_remove_last_method_call(err, expr, expected) </ins> || self.suggest_associated_const(err, expr, expected) || self.suggest_deref_ref_or_into(err, expr, expected, expr_ty, expected_ty_expr) || self.suggest_option_to_bool(err, expr, expr_ty, expected)

Discussion:
I tried this code (): I expected to see this happen: Instead, this happened: This is just a very specific instance where the suggestion to add some code, while "technically correct", is less useful than the better suggestion to remove some code. <!-- 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<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +A-diagnostics
it seems that given an expression, you can generically check if removing the last method call if present would give you the right type, so this could be implemented in a very generic way instead of special casing &str/String.
This looks awesome, thank you so much!
This is how it looks now . Very cool.