jiebi/CodeConvo huggingface dataset:
Change:
self.tcx().mk_const( ty::Const { val: ConstValue::Infer(InferConst::Canonical(self.binder_index, var.into())), <del> ty: const_var.ty, </del> <ins> ty: self.fold_ty(const_var.ty), </ins> } ) }

Discussion:
A clean rust project on the latest nightly rustc with just this : produces the following error on cargo check/build: <details</detailsThe error is most likely caused by the inability to deduce the value of the const generic parameter ; when it is made clear (with, say, ) the ICE no longer occurs. Thus the expected behavior is probably still a failure to build (just not an ICE).
EDIT: Apparently const-generics in array repeat positions isn't a thing yet, at all. I apologize for the not-even-currently-valid example. I get the same ICE for this code: <details</detailswhich does give the explicit type, so it's not (entirely) a deduction thing. Entire build log: <details</details
Could you check the ICE still appears? I cannot reproduce it with latest nightly on playground.
Although this isn't throwing an error on the playground, I get an assertion failure when adding a test: Let's leave this open until we have a test for it.

() Errors:
/cc Related to but different from
This can be avoided by expressly allowing the type to be inferred:
: (as compared to )
After , this isn't fixed, but commenting out the call will cause it to error without ICEing (at the moment, it ICEs even without that line).
I configure struct by complicated const value and get this ICE. My code does something like this: Error: Note that type erase (as proposed does not help in my case. Until I found a way around this ICE.
Same error on:
I tried to port 's from to . Some of code is commented because of this bug and several other. I think this is good test for
Cannot reproduce the ICE with the above playground link.
It should be noted that while this no longer ICEs, this is because rustc no longer attempts to infer the type parameter causing it to fail to compile.

A new project with the following code: Causes the following error:
Reduced: cc
Latest nightly shows a different compile error: error: internal compiler error: ty::TyKind::hashstable() - can't hash a TyVid _t.
Does not ICE anymore on playground - But does ICE in my local PC with latest nightly.
Can confirm it still ICE's with the latest nightly both in my little testing crate, and my larger project. The lack of ICE on the playground is very weird. Even copying my testing crate's code exactly doesn't make the ICE occur, even though both the playground and my computer run rustc .
Maybe a compiler flag? Not sure if playground uses . cc
The playground attempts to build each night, . You can always review exactly what version you are using in the channel dropdown: ! For what it’s worth, I don’t see the producing an error locally or in the playground.
Thank you very much, It is clear now that incremental compilation is the source of this behavior. To make a successful compilation with cargo, it is possible to use, for example, .
Change:
self.tcx().mk_const( ty::Const { val: ConstValue::Infer(InferConst::Canonical(self.binder_index, var.into())), <del> ty: const_var.ty, </del> <ins> ty: self.fold_ty(const_var.ty), </ins> } ) }

Discussion:
I started to further investigate the bug blocking . The following is a minimised test case: Results in (with debug assertions enabled): Here with the backtrace: <details</detailsI would love to investigate further, but I am too confused and the panic message doesn't tell me anything useful either. But please tell me if I can do anything else to help you solve the bug. I'd love to have it fixed so that I can continue working on . CC
It's this debug assertion that's failing: Debug assertions are not turned on on released artifacts, but your local probably has them enabled.
Ohhh, that explains the weirdness. Should have thought of that myself. Thanks! But anyway, it's still a bug I assume. And I couldn't find another const generic bug with this error message.
The test case is sufficient with debug assertions (I can reproduce locally). Sorry, I've been meaning to look into this for ages. Having a minimal test case is helpful.
No problem, I'm happy for every minute you spend working on const generics ^_^
Sounds like inference variables are leaking out of somewhere. EDIT: wait, canonical variables reuse some of that infra - is the definition of symmetrical between , and ?
I had a quick look, and didn't spot any obvious asymmetries, but there surely must be for this error to occur…
This doesn't seem to have an analogue anymore in /: This mentions regions even though it shouldn't:
The first has an analogue in: I'll fix the second one.
I think the problem is here: We are creating a new canonical variable for the const value but are returning the type unchanged. So if the type has inference variables in it they will leak through.
So was replaced by ? The same should be done for consts.
Opened for that.
Change:
use hash; use iter::{Iterator,range_inclusive,range_step_inclusive}; use cell::RefCell; <ins> use rand::{weak_rng, Rng}; </ins> struct KindaIntLike(int);

Discussion:
This code manipulates a HashMap using the new Entry API, checking for consistency after each step. The assertion in should never fail, but in my tests it does so reliably, almost always within the first 10 iterations of the second loop. When it does fail, the value of is not one of the values previously removed during the loop (that is, is right to return this key, and is wrong to report it as absent). I tested this with on 64-bit Linux.
cc
Fffffff--- looking into it now. cc
Oh thank god it was a simple stupid mistake, and not something complicated.
Change:
<ins> error[E0277]: the `?` operator can only be applied to values that implement `Try` --> $DIR/issue-97704.rs:9:5 | LL |     func(async { Ok::<_, i32>(()) })?; |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the `?` operator cannot be applied to type `impl Future<Output = Result<(), i32>>` | = help: the trait `Try` is not implemented for `impl Future<Output = Result<(), i32>>` help: consider `await`ing on the `Future` | LL |     func(async { Ok::<_, i32>(()) }).await?; |                                     ++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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 output might also be different depending on the Edition. --
Huh, looks like this is a case where doesn't kick in for some reason.
Ah, it's that the return type of an async function like this has . I don't know enough about rustc's typechecking to know whether this can be resolved haha.
It doesn't seem like the problem that caused is a thing anymore? I can remove the condition and it doesn't ICE on the example given in that issue.
do you know if stuff has changed such that is no longer necessary?
I actually have a PR almost up that does just exactly that, though if you want to put one up instead then feel free.
I'm pretty sure fixes this underlying issue. This method could use some additional cleanup as well.
Change:
<ins> struct X {} fn main() { vec![X]; //… //~^ ERROR expected value, found struct `X` } </ins>

Discussion:
When I used the character in comment, combined with some (invalid) code preceding it, the compiler panicked. I tried this code: I expected to see this happen: rustc compiles this code. Instead, this happened: rustc panicked with the following output : Backtrace:
Regressed in 1.34.0. Used to be:
cc
Miminized: Probably some span handcrafting?
Probably some span handcrafting? +1
I was idly curious, so I took a brief look at this. The diagnostic that triggers this was introduced in , but I don't think it is responsible for the error (it's just stepping through characters looking for a closing brace). There is some strange math in  (introduced in ). It oscillates between zero-length and 1+ length spans as it is stepping over characters. When it hits a multi-byte character, it returns an invalid span. Example: Starting with a span of (0,1), using would result in (1,1), then (1,2), then (2,2), then (2,4). That last one slices into the middle of the multi-byte character (because of , where width is 3), causing a panic. I'm not familiar enough with this stuff to say how it should behave. It seems like is being used for two different purposes (getting the next zero-length span, and getting the "next" character), and it's not clear to me what the behavior should be since it is used in a variety of places. I don't think it can be changed to always return zero-length spans, and it can't be changed to always return non-zero length spans. Perhaps there should be two different functions?
triage: P-medium, removing nomination; the ICE to me appears to include enough information for a user to identify the offending character and work-around the problem (namely by getting rid of the character). I do agree with that there should probably be two distinct functions corresponding to the two distinct purposes that they identified for the current callers of .
More test cases have been brought up in
I guess this is the same bug, but the examples I've seen here concern non-ASCII characters in comments. I'm getting a similar rustc panic from an erroneous code without comments: Compilation attempt:
Please file a new issue and reference this one.
I think it's fixed, try .
confirmed fixed by .
Change:
.emit(); } } <ins> ty::PredicateKind::Projection(ty::ProjectionPredicate { projection_ty, term }) => { tcx.sess .struct_span_err( span, &format!("cannot specialize on associated type `{projection_ty} == {term}`",), ) .emit(); } </ins> _ => { tcx.sess <del> .struct_span_err(span, &format!("cannot specialize on `{:?}`", predicate)) </del> <ins> .struct_span_err(span, &format!("cannot specialize on predicate `{}`", predicate)) </ins> .emit(); } }

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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to -- The current output is: <!-- The following is not always necessary. --Ideally the output should not reference the debug format of an internal type <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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 output might also be different depending on the Edition. -- modify labels +F-specialization +A-specialization +requires-nightly
Change:
<ins> // compile-flags: -O -C debug-assertions=on // This needs inlining followed by ConstProp to reproduce, so we cannot use "unit-test". #[inline] pub fn imm8(x: u32) -> u32 { let mut out = 0u32; out |= (x >> 0) & 0xff; out } // EMIT_MIR issue_101973.inner.ConstProp.diff #[inline(never)] pub fn inner(fields: u32) -> i64 { imm8(fields).rotate_right(((fields >> 8) & 0xf) << 1) as i32 as i64 } fn main() { let val = inner(0xe32cf20f); assert_eq!(val as u64, 0xfffffffff0000000); } </ins>

Discussion:
This code normally prints but when compiled with it produces instead. This was noticed because MIR optimization is enabled by default on the current nightly. This is the LLVM IR for the function with . Notice how the inputs to (used by ) are , which is incorrect.
prioritize
label regression-from-stable-to-nightly, I-unsound, A-mir-opt, T-compiler
Can someone execute the snippet with and upload the resulting directory somewhere? That should allow me to debug from my phone
I’ve made a gist originally, too, but it looks like you can’t see all the files there. (Afaict only 300 of the 401 files show up.) Here’s a repo Edit: One downside of a repo (compared to a gist) is that I might want to get rid of it eventually; AFAIK, this shouldn’t be needed for too long anyway though.
With an assertion instead of println: Individual builds from , point to cc
Ouch. That probably means the unsoundness was already possible before my PR (as explained there, the check it removes was ineffective), but is easier to trigger now. Cc something is wrong in ConstProp handling of shifts and/or casts and/or bit-ops. Is there a reproducer that does not need shifts and casts and a bitop? That would make the issue easier to track down.
FWIW it prints 0xfffffffff0000000 in Miri so the interpreter is probably fine, and it's probably a problem with the ConstProp pass itself.
The original code was much more complex. I minimized it as much as I could, but at this point even removing a useless will cause the bug to no longer trigger.
Yeah I quite appreciate that it does fit in a few lines now. :)
The is not needed, but indeed the bug needs to trigger. And inlining. Very strange. ConstProp code is super hard to read and full of subtle (usually barely documented) invariants, so... this could be an interesting one to track down.
The inlined code looks fine, but it has the basic blocks in a strange order, which might explain why the ConstProp bug only occurs if inlining happens first.

The code just before ConstProp has this One possible explanation would be if ConstProp iterated the basic blocks in order, then by the time it reaches , the last assignment to it saw is in bb0. There is another assignment to in bb3, which is executed before bb2, but maybe somehow my change made it so that this is not taken into account properly any more.
Turns out the actual problem was an early return that I which skipped more code than it should have -- fixed by
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
| (DefKind::AssocFn, AssocItemKind::Fn(..)) | (DefKind::AssocConst, AssocItemKind::Const(..)) => { self.r.record_partial_res(id, PartialRes::new(res)); <del> let vis = self.r.tcx.visibility(id_in_trait).expect_local(); self.r.feed_visibility(self.r.local_def_id(id), vis); </del> return; } _ => {}

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' 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: [visibility] computing visibility of [effectivevisibilities] checking effective visibilities [checkmoditem_types] checking item types in top-level module [analysis] running analysis passes on this crate --
Regression in ping
Fixed in
Change:
.iter() .map(|(op, op_sp)| match *op { hir::InlineAsmOperand::Const { ref anon_const } => { <del> let const_value = cx .tcx() .const_eval_poly(anon_const.def_id.to_def_id()) .unwrap_or_else(|_| { span_bug!(*op_sp, "asm const cannot be resolved") }); let ty = cx .tcx() .typeck_body(anon_const.body) .node_type(anon_const.hir_id); let string = common::asm_const_to_str( cx.tcx(), *op_sp, const_value, cx.layout_of(ty), ); GlobalAsmOperandRef::Const { string } </del> <ins> match cx.tcx().const_eval_poly(anon_const.def_id.to_def_id()) { Ok(const_value) => { let ty = cx .tcx() .typeck_body(anon_const.body) .node_type(anon_const.hir_id); let string = common::asm_const_to_str( cx.tcx(), *op_sp, const_value, cx.layout_of(ty), ); GlobalAsmOperandRef::Const { string } } Err(ErrorHandled::Reported { .. }) => { // An error has already been reported and // compilation is guaranteed to fail if execution // hits this path. So an empty string instead of // a stringified constant value will suffice. GlobalAsmOperandRef::Const { string: String::new() } } Err(ErrorHandled::TooGeneric(_)) => { span_bug!( *op_sp, "asm const cannot be resolved; too generic" ) } } </ins> } hir::InlineAsmOperand::SymFn { ref anon_const } => { let ty = cx

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: asm const cannot be resolved', 'error: internal compiler error: asm const cannot be resolved' 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: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2021-12-16 lol commit[0] 2021-12-14: Auto merge of - matthiaskrgr:rollup-hjjyhow, r=matthiaskrgr commit[1] 2021-12-14: Auto merge of - Amanieu:stableasm, r=joshtriplett commit[2] 2021-12-15: Auto merge of - matthiaskrgr:rollup-cw9qolb, r=matthiaskrgr commit[3] 2021-12-15: Auto merge of - matthiaskrgr:rollup-jszf9zp, r=matthiaskrgr commit[4] 2021-12-15: Auto merge of - yaahc:track-caller-result, r=cuviper commit[5] 2021-12-15: Auto merge of - matthiaskrgr:rollup-rhajuvw, r=matthiaskrgr commit[6] 2021-12-15: Auto merge of - matthiaskrgr:rollup-2g082jw, r=matthiaskrgr ERROR: no CI builds available between and within last 167 days ~/vcs/github/rustbisect via v1.78.0-nightly too I would guess ? cc
Doubt it, that's just when the stabilization happened, there's no meaningful changes there
Actually bisects to which support for in .
label +F-asm +A-inline-assembly +F-inline_const -needs-triage
cc
claim
Change:
rustc_hir = { path = "../rustc_hir" } rustc_index = { path = "../rustc_index" } rustc_infer = { path = "../rustc_infer" } <ins> rustc_lint_defs = { path = "../rustc_lint_defs" } </ins> rustc_macros = { path = "../rustc_macros" } rustc_session = { path = "../rustc_session" } rustc_span = { path = "../rustc_span" }

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: This should probably continue to compile as before, unless proven to be equivalent. Instead, this happened: The detection for seems to be a little too aggressive, so it's flagging the coercion as feature-gated in beta even though a deref coercion is available: Playground: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.55.0 : <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<!--<details<summaryBacktrace</summary<p</p</details--(not applicable) <!-- 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-beta -regression-untriaged
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Bisection: searched nightlies: from nightly-2020-01-01 to nightly-2021-09-23 regressed nightly: nightly-2021-08-01 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
There is a that discusses this issue. Tagging this with T-lang since this is a change in semantics.

label +A-traits +F-trait_upcasting +T-lang +T-compiler
I'm not sure what the proper procedure is in this case, but I just noticed this hit stable in 1.56.0 (without the lint appearing beforehand) and broke my crate I'll work around it on my end, since I need this to continue work on a downstream crate.
Hmm, it seems that the fix didn't get backported to 1.56. Does 1.57-beta work?
It does indeed: The playground uses as of writing this.
Change:
unsafe { *their_packet.result.get() = Some(try_result) }; }; <del> if let Some(scope_data) = scope_data { </del> <ins> if let Some(scope_data) = &my_packet.scope { </ins> scope_data.increment_num_running_threads(); }

Discussion:
The following code sometimes causes a data race to be reported by Miri: Miri reports: The deallocation occurs when returns and its local variable gets deallocated. The read occurs here (I am fairly sure): This reads the contents of the field after the . But the moment the is done, the memory backing might be deallocated. That makes the read a potential use-after-free, and a race with the deallocation. Cc
The following patch fixes this: However, even with this patch, we still run into a problem like the gets deallocated while still runs. This is still UB even after my proposed because contains a field that is not inside an (the field). So that part of what points to is expected to stay live for the entire duration of the function call. Another alternative might be to put the entire into an rather than allocating it on the stack frame of .
Going to attach this to the 1.63 milestone, since this is in a newly stabilized feature -- we may wish to back out stabilization for a cycle or backport fixes.
Re-opening for beta backport.
The fix was backported in .
Change:
query_result_index: EncodedDepNodeIndex, side_effects_index: EncodedDepNodeIndex, // The location of all allocations. <del> interpret_alloc_index: Vec<u32>, </del> <ins> // Most uses only need values up to u32::MAX, but benchmarking indicates that we can use a u64 // without measurable overhead. This permits larger const allocations without ICEing. interpret_alloc_index: Vec<u64>, </ins> // See `OnDiskCache.syntax_contexts` syntax_contexts: FxHashMap<u32, AbsoluteBytePos>, // See `OnDiskCache.expn_data`

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. --: I see similar behavior in stable : The example always succeeds to compile the first time, but uses a large amount of time and memory. : Upon incremental re-compilation, I almost always see one of the following errors. I saw other open issues with a similar error message as the 1.46.0 output below, but in this one the error is affected by the value the array was filled with. : Running sometimes yields a different yet similar error: On 1.46.0: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pOn 1.46.0: </p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
do you know if this is still a problem for you? claim
On 1.66.0, I still get an error upon incremental recompilation with the same code: <details<summary<strongBacktrace</strong</summary</details
Oh wow I didn't know anyone actually hit this so long ago! I turned this into a much nicer panic a few months ago: