jiebi/CodeConvo huggingface dataset:
Change:
let hashes_size = self.capacity * size_of::<u64>(); let keys_size = self.capacity * size_of::<K>(); <del> let buffer = self.hashes.0 as *mut u8; </del> <ins> let buffer = self.hashes as *mut u8; </ins> let (keys_offset, vals_offset) = calculate_offsets(hashes_size, keys_size, min_align_of::<K>(), min_align_of::<V>()); unsafe { RawBucket { <del> hash: self.hashes.0, </del> <ins> hash: self.hashes, </ins> key:  buffer.offset(keys_offset as int) as *mut K, val:  buffer.offset(vals_offset as int) as *mut V }

Discussion:
This compiles, despite Rc<T: !Send. I'm guessing this is because RawTable only uses K and V with marker::CovariantType, and I guess that isn't enough for the negative-impl to propagate. I haven't checked which other collections might be unsafe.
It appears that this also isn't specifically related to trait bounds: cc
Ah, yeah. RawTable contains only a , which is of course always Send/Sync. It should presumably just contain a plain and impl Send/Sync conditionally?
Or we need a more rich marker type.
may be a good replacement for the current system as it could contain a marker of and for example. For now though a manual impl of and will probably be required. Should other collections with an unsafe representation also be audited?
I can say confidently this is the only problem case in collections. It's the only collection that uses basically a pointer.
ok cool, good to know!
Change:
}, Some(ast_map::NodeStmt(_)) => "statement", Some(ast_map::NodeItem(it)) => item_scope_tag(&it), <ins> Some(ast_map::NodeTraitItem(it)) => trait_item_scope_tag(&it), Some(ast_map::NodeImplItem(it)) => impl_item_scope_tag(&it), </ins> Some(_) | None => { err.span_note(span, &unknown_scope()); return;

Discussion:
Receiving info about MIR or some other intermediate form in a user error report. I tried this code which most likely has some lifetime issue that I am yet to resolve: I should have received information about the scope defined by some part of my code or if the issue is with auto-generated code then possibly no information about an internal scope. Instead, this happened: :
This seems to be more common than I first thought: Made a resulted in:
Issue exists in latest nightly as well.
Can confirm experiencing it. Smaller sample: Not an issue in current stable or beta, which reports rather than
Does this qualify as a regression?
Yes, though not the kind we'd do a point release for, IMO
should mark as such then :)
Here's another small one:
It took me a minute to figure out that this issue is about the error message & not the error. I've also been getting CallSiteScope and so on nonsense in my error output recently. This seems like a pretty serious regression in the usability of our error messages! My impression has been that this impacts just about every lifetime issue I've been getting recently, but I could be wrong. Could we get this fixed by next stable release? I disagree with that this isn't worth making a point release for (currently its only in nightly, so that's not an issue).
Nominated for consideration by the compiler team.
This appears to be in beta (testing on the playground). Super tiny repro: gives
Has nobody looked into this? I'll take a peek before the compiler meeting today. EDIT: Of course it was me who introduced this bug, or rather triggered sigh. EDIT2: Basically, after , any uses of are suspicious. I'll try to make a PR.
Fix is at , using reduction as the testcase for this issue.
triage: P-high We have a fix though =)
Change:
pub enum NonStructuralMatchTy<'tcx> { Adt(&'tcx AdtDef), Param, <ins> Dynamic, </ins> } /// This method traverses the structure of `ty`, trying to find an

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. --: Note that the error is also present on stable (1.42.0). <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
cc I don't think should be structurally matchable.
Note that this isn't matching on , it's matching on . There's a double pointer indirection because AtomicPtr requires T to be Sized.
References match by their pointee value, unlike raw pointers. You should use if you want to actually compare the pointers.
Change:
pub enum NonStructuralMatchTy<'tcx> { Adt(&'tcx AdtDef), Param, <ins> Dynamic, </ins> } /// This method traverses the structure of `ty`, trying to find an

Discussion:
Pretty straightforward. The idea is to plug logic into a template. This seems like something that should/could work. Playground link: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
"smaller": Error:
claim
release-assignment is not structural match so this should not compile. We probably shouldn't ICE here though :laughing: cc
It shouldn't be, but it currently is. To fix it you need to change , .
Change:
} pub fn is_sized(&'tcx self, <del> tcx: TyCtxt<'a, 'tcx, 'tcx>, param_env: ty::ParamEnv<'tcx>, span: Span)-> bool </del> <ins> tcx_at: TyCtxtAt<'a, 'tcx, 'tcx>, param_env: ty::ParamEnv<'tcx>)-> bool </ins> { <del> tcx.at(span).is_sized_raw(param_env.and(self)) </del> <ins> tcx_at.is_sized_raw(param_env.and(self)) </ins> } pub fn is_freeze(&'tcx self,

Discussion:
One example is the method on . Internally it creates a , when it could simply be taking exactly that as an argument. In miri I had to write which just feels a little riddiculous (taking apart the , just to have the method construct it back). There's probably many other similar methods and functions that should be taking a
Can I take this one if no one is working on that ?
it's all yours!
Change:
// Member constraints can also give rise to `'r: 'x` edges that // were not part of the graph initially, so watch out for those. // (But they are extremely rare; this loop is very cold.) <del> for constraint in self.applied_member_constraints(r) { </del> <ins> for constraint in self.applied_member_constraints(self.constraint_sccs.scc(r)) { </ins> let p_c = &self.member_constraints[constraint.member_constraint_index]; let constraint = OutlivesConstraint { sup: r,

Discussion:
File: reduced: original: Version information Command: Program output:
cc
Some notes dump: the original test fuzzed into this MCVE is . NLLs and do compute the same scopes on that original difference in scopes here is on a somewhat ambiguous case in the current implementation: the loan ultimately flows into via member constraints, not a regular outlives constraint. NLL still computes a scope for it, doesn't since it considers the loan to escape the we ignored the member constraint here and computed the scope anyways, it would result in the same results as NLLs and not trigger the assert. A handful of other tests would then fail of SCC member constraints difference between this test and these other 4 seems to me to be about applied member constraints. That is, in this test the member constraint is likely not applied, so maybe the loan should only be considered to escape via these. We had discussed this very subject before, but thought the distinction didn't matter for the purpose of computing scopes -- maybe we were wrong in these edge cases. That should be a correct fix and should work on these 5 tests. So I'll look into that next.
Change:
use realstd::collections::CollectionAllocErr::*; use realstd::usize; <ins> // https://github.com/rust-lang/rust/issues/62301 fn _assert_hashmap_is_unwind_safe() { fn assert_unwind_safe<T: crate::panic::UnwindSafe>() {} assert_unwind_safe::<HashMap<(), crate::cell::UnsafeCell<()>>>(); } </ins> #[test] fn test_zero_capacities() { type HM = HashMap<i32, i32>;

Discussion:
Successfully compiles on stable 1.35, fails on beta/pre 1.36.
First reported to FireFox ESR and shared on irlo here:
The impl for requires , but the one for requires .
is a possible fix.
Change:
<ins> // edition:2018 // check-pass #![feature(unboxed_closures)] use std::future::Future; async fn wrapper<F>(f: F) where for<'a> F: FnOnce<(&'a mut i32,)>, for<'a> <F as FnOnce<(&'a mut i32,)>>::Output: Future<Output=()> + 'a { let mut i = 41; f(&mut i).await; } async fn add_one(i: &mut i32) { *i = *i + 1; } fn main() {} </ins>

Discussion:
Hello, I am getting an ICE while "playing" with  MCVE can be found here: <details<summaryOriginal</summary</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. --: (from Playground) <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
A project maintainer might want to add the label.
Reduced, no nightly features: Output on stable: ICEs on beta and nightly.
Adding a bound as suggested gives this ICE on stable: <details<summaryBacktrace</summary</detailsWhich looks like . It still gives the original ICE on beta and stable, and it looks like 's code now produces the original ICE of this issue on beta and stable. Does that make this a duplicate?
:
modify labels: -F-unboxed_closures -requires-nightly per
This is now reproducing on stable. This feels like more of a "guts of the borrow checker" kind of issue than async/await-specific, so I'm tagging with .
Assigning as and removing .
Another repro from :
Change:
use thin_vec::{thin_vec, ThinVec}; use crate::errors::{AddedMacroUse, ChangeImportBinding, ChangeImportBindingSuggestion}; <del> use crate::errors::{ConsiderAddingADerive, ExplicitUnsafeTraits, MaybeMissingMacroRulesName}; </del> <ins> use crate::errors::{ ConsiderAddingADerive, ExplicitUnsafeTraits, MacroDefinedLater, MacroSuggMovePosition, MaybeMissingMacroRulesName, }; </ins> use crate::imports::{Import, ImportKind}; use crate::late::{PatternSource, Rib}; use crate::{errors as errs, BindingKey};

Discussion:
Often times, the actual error of the attempted call and the warning of the unused macro can be apart and/or soaked in other errors. Due to this, it might be desirable to couple a help message addressing this specific situation of a later definition. This might also be useful advice for beginners who are just starting out with Rust and might not be aware of the horrors of declarative macros using , and as such could appreciate a helping hand by the compiler here. No response_ I tried to keep the suggested output close to the one for similarly named macros/variables, but that might not be applicable here and instead deserve its own section under the code excerpt. Open for bikeshedding. Like all of this, actually. Hmm. (The message is the same on nightly 2024-02-12.)
label +D-terse +D-newcomer-roadblock
Thank you!!
Change:
use std::any::Any; use std::ffi::CStr; use std::io::Write; <ins> use std::mem::ManuallyDrop; </ins> mod back { pub mod archive;

Discussion:
After using command random dependencies throw error. I'm 100% sure that dependencies I'm trying to build are valid because at every compile attempt different dependency fails e.g. tomledit, crossbeam-channel, actix-router_. Sometimes none of imported dependencies fail and out of 5 attempts I was able to build project succesfully twice (I deleted folder after each attempt). Example output: some dependencies (in my case 23) command Improve build scripts on Windows ARM?
Thanks for the report! Transferred to rust-lang/rust since this is a compiler issue. I'm able to reproduce, though I am also using Parallels on an aarch64 mac. I do not have native Windows ARM hardware to test, so I'm not sure if this is unique to the M2 or Parallels. If someone has native hardware, it might be good to help with testing to see if it is a general problem with the target. This appears to be a regression, and I have bisected to cc
I'm seeing the same issue intermittently on a project that uses . It looks like we might have a UAF on an LLVM object. <details<summaryCrashing stack</summary</details<details<summaryEarlier "untrack" operation</summary</detailsI'm guessing this might be triggered because causes us to drop the LLVM TargetMachine dropping the LLVM context.
Swapping the drop order back to the way we had it originally makes my reproducer compile successfully.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Re-opening to track backports
I encountered this issue in Github CI yesterday. It only occurs with rust-1.74 but not with 1.73 and lower.
this should be fixed by and included in the upcoming 1.74.1 stable release. You can probably try a nightly rustc build if you're curious to test the fix.
74.1 has been released.
Yes fixed it.
Hi, sorry for reply to the closed issue, but since I updated my M2 macbook to Sonoma 14.2 last week, I randomly got similar issue
This is happening again with Full log here
Please open a new issue, but it might also have something to do with
Change:
let x = self.parse_seq_to_before_end( &token::Gt, SeqSep::trailing_allowed(token::Comma), <del> |p| p.parse_ty(), </del> <ins> |p| p.parse_generic_arg(), </ins> ); match x { Ok((_, _, false)) => {

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: Ideally the output should mention that the user needs to use a turbofish here: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
the help message seems to only be missing if there are 2 const arguments: using type parameters or just one const param causes a useful help message
claim
It turns out 's repro is different than the original repro. My PR fixes 's examples but not the original one. I'll update it to fix the original one too.
All fixed.
Change:
<ins> error[E0308]: mismatched types --> $DIR/bad-subst-const-kind.rs:8:31 | LL | impl<const N: u64> Q for [u8; N] { |                               ^ expected `usize`, found `u64` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Regression in searched nightlies: from nightly-2023-03-10 to nightly-2023-03-18 regressed nightly: nightly-2023-03-12 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
We relate with during codegen when selecting an impl which now eagerly returns without constraining to anything wheras previously it would have been instantiated with . This then results in codegen returning an impl with in the substs from a query
output on beta/stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<ins> error[E0072]: recursive type `ElemDerived` has infinite size --> $DIR/issue-72554.rs:4:1 | LL | pub enum ElemDerived { | ^^^^^^^^^^^^^^^^^^^^ recursive type has infinite size LL |     A(ElemDerived) |       ----------- recursive without indirection | = help: insert indirection (e.g., a `Box`, `Rc`, or `&`) at some point to make `ElemDerived` representable error: aborting due to previous error For more information about this error, try `rustc --explain E0072`. </ins>

Discussion:
erroneous recursive types (without being wrapped with ) having methods whose return type is causes the assertion failure.I expected the error message "recursive type has infinite size." Indeed, if there is no method with return type , we got the following normal error messages:aborted with the following assertion failure.:
glacier
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
glacier
Error: Parsing glacier command in failed: ...'cier https' ''... Please let know if you're having trouble with this bot.
glacier ""
Error: The feature is not enabled in this repository. To enable it add its section in the in the root of the repository. Please let know if you're having trouble with this bot.
Oh, we must have enabled this... Sorry for the noise!
I think now we could... glacier ""
Making the following change: makes the output look correct, but I am not sure of whether that should be the fix, making it always a and continue returning the or make the caller return instead (which seems to me to be the correct behavior). I do not understand why this has to panic in the first place.
Triage: Seems the ICE is fixed with the latest nightly, now catches this correctly (not bisected yet). Marking as E-needs-test, cc for awareness.
Change:
cargo.arg("--").args(builder.config.cmd.test_args()); <del> builder.add_rustc_lib_path(compiler, &mut cargo); </del> <ins> cargo.add_rustc_lib_path(builder, compiler); </ins> builder.run(&mut cargo.into()); }

Discussion:
I tried to build rust right after got merged and caught error:
cc
What command did you run?
Change:
<ins> #![feature(coverage_attribute)] //@ edition: 2021 // Regression test for <https://github.com/rust-lang/rust/issues/122738>. // These code patterns should not trigger an ICE when allocating a physical // counter to a node and also one of its in-edges, because that is allowed // when the node contains a tight loop to itself. fn loopy(cond: bool) { let true = cond else { loop {} }; } // Variant that also has `loop {}` on the success path. // This isn't needed to catch the original ICE, but might help detect regressions. fn _loop_either_way(cond: bool) { let true = cond else { loop {} }; loop {} } // Variant using regular `if` instead of let-else. // This doesn't trigger the original ICE, but might help detect regressions. fn _if(cond: bool) { if cond { loop {} } else { loop {} } } #[coverage(off)] fn main() { loopy(true); } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Cinstrument-coverage -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'attempt to add a to a BCB target with existing incoming edge counters'', 'thread 'rustc' panicked at 'attempt to add a to a BCB target with existing incoming edge counters'' 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: [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
cc ^_^
Further reduced:
(Also note that even before this presumably would have still ICEd, because the only thing we did with that error was unwrap it.)
I think the assertion is just incorrect in this case. Normally a BCB will only have a physical counter if it has exactly one in-edge. If it has multiple in-edges, it will get an expression that sums up all of its in-edges, most of which will have physical counters. That's what the assertion is verifying. However, if a BCB has an out-edge back to itself (i.e. ), it gets a physical counter regardless. The assertion doesn't account for this, and fails. Perhaps the reason we haven't seen this before is that the other in-edge to the loop node usually happens to be the one chosen to get an expression, so the assertion never sees the two-counters case.
I tried to fix the assertion itself, but that ended up being pretty complicated. The information we'd need isn't readily available in the place that we need it, and there's also a related assertion in that has the same problem. Given that these assertions aren't load-bearing (the code should work fine even if it's violated), I'm inclined to just rip them out. They only exist as a holdover from the original implementation anyway.
Change:
// Stitch the list of outer attributes onto the return value. // A little bit ugly, but the best way given the current code // structure <del> let res = self.parse_expr_dot_or_call_with_(e0, lo); </del> <ins> let res = ensure_sufficient_stack( // this expr demonstrates the recursion it guards against || self.parse_expr_dot_or_call_with_(e0, lo), ); </ins> if attrs.is_empty() { res } else {

Discussion:
I was trying to run rust code extracted from Coq using the plugin resulting in this project: The original program is in , some operations on a binomial queue. It does compile when setting the environment var, as suggested in the seemingly related , so feel free to close. It may be due to a deep nesting of function calls, (the successor constructor of the naive representation of natural numbers in Coq). I expected to see this happen: successful compilation Instead, this happened: rustc stackoverflow with this : : <details<summaryBacktrace</summary<p</p</details
Please specify the build command you used. Did you build this with optimizations or what?
Oh, I'm sorry, I misunderstood. No, is not quite related because it's in LLVM. This is in rustc. Maybe we should be using in more places in the Parser?
Included the file.
Pulled out a debuginfo'd backtrace from gdb and quickly found this very regular period: At first glance I thought that was the problem, while recursing into the rhs, but it seems that was only an artifact of the visible symbols in the backtrace. Funnily enough, the is period-breaking, but we've run out of stack by the time we hit it!
Pretty cool to get this fixed in a day, thanks
Change:
<ins> // Copyright 2014 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. // error-pattern:internal error: entered unreachable code fn main() { unreachable!() } </ins>

Discussion:
In we had the submitter change a to an as follows: We felt that better communicated the intent of "this code should never panic assuming that the implementation is correct" (as opposed to , which communicates "this code should never panic assuming that the user passes in the correct inputs" (cf. indexing, division) and is generally to be avoided in the stdlib). However, I think it's a shame that by expressing the intent more clearly in the code we're simultaneously losing information regarding which invariant was violated in order to reach the unreachable code. Note that this isn't really a huge deal, because we can just move the "Invalid SearchStack" bit over into a comment next to . It's also not really a huge deal for the theoretical bug reporter who's filing an issue upon hitting this code, since still includes a filename and line number in its output. However, given the precedent of optional messages set by , I don't think it would be a stretch to imagine that could also have an optional message. Usage for the typical case would be the same: could optionally look like this:
I'll have a go at implementing this.