jiebi/CodeConvo huggingface dataset:
Change:
} (Place::Promoted(p1), Place::Promoted(p2)) => { if p1.0 == p2.0 { <ins> if let ty::TyArray(_, size) = p1.1.sty { if size.unwrap_usize(tcx) == 0 { // Ignore conflicts with promoted [T; 0]. debug!("place_element_conflict: IGNORE-LEN-0-PROMOTED"); return Overlap::Disjoint; } } </ins> // the same promoted - base case, equal debug!("place_element_conflict: DISJOINT-OR-EQ-PROMOTED"); Overlap::EqualOrDisjoint

Discussion:
Error: This only happens after cc The code that triggered this is .
cc seems like we need to report an error instead of panicking as originally written
Oh it's probably because we do promote
created a fix in , but I have no minimal repro and no time today
To clarify: you're making this an error? I don't see why we can't allow to be promoted.
good point
This ICE is currently causing errors in the , and crates in
I have tried building and it does not reproduce the issue for me on master or nightly :confused: trying a stage2 build now still can't repro on regex, but can repro on OPs file now.
ok, fix exists now
It looks like we've fixed the ICE here but there's still a change in behavior here, as well as a faulty diagnostic; this is while compiling cargo-registry from (at least the version in rustc-perf).
Change:
// output archive to the same location as an input archive on Windows. drop(self.src_archives); <del> archive_tmpfile .persist(output) .map_err(|err| io_error_context("failed to rename archive file", err.error))?; </del> <ins> fs::rename(archive_tmpfile_path, output) .map_err(|err| io_error_context("failed to rename archive file", err))?; archive_tmpdir .close() .map_err(|err| io_error_context("failed to remove temporary directory", err))?; </ins> Ok(any_entries) }

Discussion:
Given this code: I get this output from rustc: The most recent archive no longer has the "read" permission bit set for group/world owners. This ended up breaking because our files are built in a container with a different user and aren't then readable outside of the container. There's no particular reason we do this and we can work around this, but I also suspected that the change in permissions here probably wasn't intentional. I think this is due to (cc specifically . I haven't dug too deeply but my guess is that temp files specifically turn off other permission bits
reverted back to the LLVM archive writer to fix another regression. Still I think this issuw should be kept open as a reminder to fix the new archive writer before it becomes the default again.
cc , which also needs to be fixed before relanding the archive writer change. BTW is there a tracking issue for that somewhere? I see the original PR linked to , but it hasn't been reopened.
I have kept all issues that need to be fixed before it can land again in my github notifications. There is currently no tracking issue, but feel free to open one. It did probably be a good idea to ensure no issue is forgotten about.
Change:
| DefKind::Impl { .. } | DefKind::Closure | DefKind::Generator => true, <del> DefKind::ForeignMod | DefKind::ImplTraitPlaceholder | DefKind::LifetimeParam | DefKind::GlobalAsm => false, </del> <ins> DefKind::ForeignMod | DefKind::ImplTraitPlaceholder | DefKind::GlobalAsm => false, </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. --cc still crashes after <!-- 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 --
Sigh, yeah, this is just the same bug but for lifetime params. I'll fix it, shouldn't be too hard. claim
Hey, , thanks for getting this fixed! Unfortunately, I seem to be running into the same issue (or a very similar one) using the latest nightly, and I've not been able to create a standalone reproducer: <details<summaryBacktrace</summary<p</p</detailsSorry if this is the wrong place to be reporting this ICE, but I wasn't sure whether to file a new issue or maybe get one of the resolved issues re-opened. Thank you!
Change:
use tracing::debug; macro_rules! gate_feature_fn { <ins> ($visitor: expr, $has_feature: expr, $span: expr, $name: expr, $explain: expr, $help: expr) => {{ let (visitor, has_feature, span, name, explain, help) = (&*$visitor, $has_feature, $span, $name, $explain, $help); let has_feature: bool = has_feature(visitor.features); debug!("gate_feature(feature = {:?}, span = {:?}); has? {}", name, span, has_feature); if !has_feature && !span.allows_unstable($name) { feature_err_issue(&visitor.sess.parse_sess, name, span, GateIssue::Language, explain) .help(help) .emit(); } }}; </ins> ($visitor: expr, $has_feature: expr, $span: expr, $name: expr, $explain: expr) => {{ let (visitor, has_feature, span, name, explain) = (&*$visitor, $has_feature, $span, $name, $explain);

Discussion:
This code (): prints out This is pretty unhelpful for beginners - normally this happens when they try to use in a closure, which tells them they need async: But when they do they get an error about async being unstable, which they have no idea how to solve. The fix is to remove the pipe symbols: However, this requires knowledge that async blocks desugar internally into closures, which is not at all clear from the syntax. It would be better for the compiler to suggest it:
Hey, I saw this and it looked like it might be easy so I took a shot with I haven't fixed the tests yet because I wasn't sure if this approach is reasonable or not. You end up with Re-ordering the note and help, or adding a nested span on to put the help would be considerably more involved.
Given the current is equivalent to , it may be preferable to suggest instead of .
the point of this is that the user didn't mean though. If you add then you can no longer await it: For context, the original code was something like , where the user tried to use outside of an async function.
Thanks for clarifying. What suggestion is preferable seems to depend on the expected return type. Perhaps it is preferable to have both notes?
Change:
unsafe { SourceIter::as_inner(&mut self.iter) } } } <del> #[unstable(issue = "none", feature = "inplace_iteration")] unsafe impl<I: InPlaceIterable> InPlaceIterable for Peekable<I> {} </del>

Discussion:
This code leads to an out of bounds write, makes the assert fail and triggers miri: The problem is that after cloning a the inner iterator can no longer be considered advanced, but the may still yield the peeked element without advancing it, thus breaking the contract of .
This can be fixed by either removing from or by changing the impl of to clone the exact state of rather than allocating a smaller one. The latter may be unnecessarily costly when cloning a mostly-exhausted iterator, but on the other hand it would preserve the optimization. So I'd try the first one first and do a perf run to see what the impact is (when it was introduced it mostly helped rustdoc) and try the latter if there's a significant regression.
It may also be possible to fix this by specializing on to look into its (if available) and do a custom clone of its source. I'll see if specialization is powerful enough to pull that off.
Hrm, I think it would be possible to do that but it would require some additional helper traits or methods tailored to just this use-case since doesn't know about . That's probably too much hackery for this optimization.
This also effects stable modify labels: regression-from-stable-to-stable
Is it a regression though? Marking as according to the . modify labels -I-prioritize +P-critical
Technically when was merged it broke any crate that used code like this (which is not that unexpected like exploting panics and stuff like that). In fact I found this bug due to a project written in only safe rust code that was segfaulting
Change:
Applicability::MaybeIncorrect, ); } else { <del> let sugg_fmt = match args.explicit_args().len() { 0 => "{}".to_string(), count => { format!("{}{{}}", "{} ".repeat(count)) </del> <ins> // `{}` or `()` let should_suggest = |kind: &ExprKind| -> bool { match kind { ExprKind::Block(b, None) if b.stmts.is_empty() => true, ExprKind::Tup(v) if v.is_empty() => true, _ => false, </ins> } }; <ins> let mut sugg_fmt = String::new(); for kind in std::iter::once(&efmt.kind) .chain(args.explicit_args().into_iter().map(|a| &a.expr.kind)) { sugg_fmt.push_str(if should_suggest(kind) { "{:?} " } else { "{} " }); } sugg_fmt = sugg_fmt.trim_end().to_string(); </ins> err.span_suggestion( unexpanded_fmt_span.shrink_to_lo(), "you might be missing a string literal to format with",

Discussion:
Cargo does not seem to be detecting the {} outside brackets and provides an incredibly strange fix instead. No response the file is from here: You will need serdejson crate. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
it's worth noting that is a valid rust expression, it evaluates to the empty tuple. this is perfectly valid code: minimal repro:
huh, didn't know that. good to know ig
I think it is worth special casing this in diagnostics though, if someone wanted to print a unit type (for some reason?) they probably should use the value or just embed it directly in the format string. An empty expression as the first argument of a format macro is almost certainly a mistake.
claim
The PR that closed this doesn't seem to actually apply the wanted fix, this should be reopened.
Hello, thank you very much for the suggestion. My idea is to find a slightly more general solution instead of special treatment for rare cases. If you think it should be modified as , I completely agree with reopening the issue. :relaxed:
Change:
# ============================================================================= [llvm] <ins> # Indicates whether LLVM rebuild should be skipped when running bootstrap. If # this is `false` then the compiler's LLVM will be rebuilt whenever the built # version doesn't have the correct hash. If it is `true` then LLVM will never # be rebuilt. The default value is `false`. #skip-rebuild = false </ins> # Indicates whether the LLVM build is a Release or Debug build #optimize = true

Discussion:
The compiler LLVM is rebuilt whenever the built version of LLVM doesn't have the right hash. (Previously it was rebuilt based on a special marker file, which was easier to work around.) However, most of the time, having the latest LLVM version is not necessary, but makes rebuilding rustc after rebasing take significantly longer, which is a pain. It would be good to be able to disable this as an option in for convenience. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
To fix this, you'll want to add another option: you should be able to look at the logic for something like .
It would be good if this could be changed in the config file so you don't have to pass in the option all the time.
if it's a config file option, then there should be an option to rebuild it if necessary. I.e. it shouldn't be necessarily to temporarily change the to rebuild.
sure that seems good, although they can be implemented separately.
The line you would need to change is near this one: (line 735 of ) It would probably be much easier to add a check against a key in the config, than to add a new flag.
claim
Error: Parsing assign command in failed: claim ... Please let know if you're having trouble with this bot.
, my bad! claim EDIT: oh dear, I'm making it worse
are you still working on this? I wouldn't mind picking it up if not. (Sorry - not really sure what the etiquette is re: dormant tickets!)
Just saw that PR () lapsed. I'm gonna claim this, if that's okay. Will work on something based on the existing comments there. claim
Thank you for picking this up! Getting things fixed is the important thing, and I'm sure I'll find something else to fix in the near future when I have more time
Change:
pub render_span: Option<MultiSpan>, } <del> #[derive(PartialEq, Eq)] </del> <ins> #[derive(Debug, PartialEq, Eq)] </ins> pub struct DiagnosticStyledString(pub Vec<StringPart>); impl DiagnosticStyledString {

Discussion:
On E0308 type mismatch errors we already perform a basic check to type arguments in order to only highlight differences between the expected and found type. I recently came across a case where the two types had identifiers of the same length with no type arguments, but that were not local so the path was quite long. It took me some time to realize that the two types were actually different and not caused by different crate versions. It'd be nice if for the following, only the parts of the path that differ were highlighted/bolded in the CLI output: CC
Hello, I'd like to implement this feature.
Hi Will you be needing a hand? To begin with, I would recommend searching for in order to find how it works today. Particularly, shows how the highlighting for specific type arguments is currently handled. It is extremely verbose, but the comments should help somewhat. Also, the is a good primer on how to develop in the compiler's codebase. If you need a hand, don't hesitate to reach out.
Thanks, I'd found that struct and file, but I'd overlooked that method due to how complicated it seemed at a glance.
Should I add a test for this? If so, how would I implement that? The standard UI testing method doesn't seem to track highlights.
sadly, we do not have any way to test correct application of colors in the test suite. Attach screenshots to the PR so that we can see the changes, but we have to rely on being extra careful when touching this part of the codebase.
Change:
} }, AssocConstraintKind::Bound { ref bounds } => { <ins> self.record_lifetime_params_for_impl_trait(constraint.id); </ins> walk_list!(self, visit_param_bound, bounds, BoundKind::Bound); } }

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 nightly-2023-08-29 Regression in cc
Change:
<ins> // Make sure that the MIR inliner does not loop indefinitely on polymorphic recursion. // compile-flags: --crate-type lib // Randomize `def_path_hash` by defining them under a module with different names macro_rules! emit { ($($m:ident)*) => {$( pub mod $m { pub trait Tr { type Next: Tr; } pub fn hoge<const N: usize, T: Tr>() { inner::<N, T>(); } #[inline(always)] fn inner<const N: usize, T: Tr>() { inner::<N, T::Next>(); inner::<N, T::Next>(); } } )*}; } // Increase the chance of triggering the bug emit!(m00 m01 m02 m03 m04 m05 m06 m07 m08 m09 m10 m11 m12 m13 m14 m15 m16 m17 m18 m19); </ins>

Discussion:
I tried this code with (, ; minimized and modified from 's ): I expected to see this happen: Successful compilation Instead, this happened: Compiler hangup <!-- 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<summaryBacktrace</summary<pCaptured by a command in GDB:  </p</details
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<ins> // compile-flags: -Zpolymorphize=on -Zinline-mir=yes -Zmir-opt-level=0 #![feature(fn_traits, unboxed_closures)] struct Foo<T>(T); impl<T: Copy> Fn<()> for Foo<T> { extern "C" fn call(&self, _: ()) -> T { //~^ ERROR method `call` has an incompatible type for trait match *self { Foo(t) => t, } } } impl<T: Copy> FnMut<()> for Foo<T> { extern "rust-call" fn call_mut(&mut self, _: ()) -> T { self.call(()) } } impl<T: Copy> FnOnce<()> for Foo<T> { type Output = T; extern "rust-call" fn call_once(self, _: ()) -> T { self.call(()) } } fn main() { let t: u8 = 1; println!("{}", Foo(t)()); } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '-Zmir-opt-level=0 -Zpolymorphize=on -Zinline-mir=yes -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'index out of bounds: the len is 6 but the index is 6'', 'thread 'rustc' panicked at 'index out of bounds: the len is 6 but the index is 6'' 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: [optimizedmir] optimizing MIR for [unusedgenericparams] determining which generic parameters are unused by [analysis] running analysis passes on this crate --
cc
Change:
pprust::AnnNode::Block(blk) => blk.hir_id.local_id, pprust::AnnNode::Item(_) | pprust::AnnNode::SubItem(_) => return, <del> pprust::AnnNode::Pat(pat) => pat.hir_id.local_id </del> <ins> pprust::AnnNode::Pat(pat) => pat.hir_id.local_id, pprust::AnnNode::Arm(arm) => arm.hir_id.local_id, </ins> }; if !self.has_bitset_for_local_id(id) {

Discussion:
ICE with the borrow checker on nightly. Tried on stable/beta and it correctly errors with in nightly, I get : Backtrace:
Reduced: cc
Bisected this one to and , that is, PR . cc
Change:
+ +     bb8: { +         _1 = CoroutineState::<i32, bool>::Yielded(move _8); <ins> +         StorageDead(_8); </ins> +         discriminant((*_6)) = 3; +         goto -> bb4; +     }

Discussion:
Reproduces with on commit Remove and add to get a lot of ICEs like this:
So, looks like we should either allow StorageLive on an already live local, or we need to ensure that all locals are explicitly marked StorageDead before returning. No idea how realistic it is to achieve the latter. Cc
Change:
#![allow(dead_code)] <del> fn foo<F: Fn<(), ()>>(mut f: F, mut g: F) { </del> <ins> fn foo<F: Fn()>(mut f: F, mut g: F) { </ins> Fn::call(&g, ()); //~ ERROR explicit use of unboxed closure method `call` FnMut::call_mut(&mut g, ()); //~ ERROR explicit use of unboxed closure method `call_mut` FnOnce::call_once(g, ()); //~ ERROR explicit use of unboxed closure method `call_once`

Discussion:
We do not expect to completely "unfeature-gate" unboxed closures for 1.0. We wish to reserve the flexibility to change a few aspects: to variadic generics in place of auto-tupling. the and arguments from input types to (possibly) associated types. (cc ) the coherence story with respect to fn-trait hierarchy. (cc ) To this end we will adjust the features to: [ ] Disallow references to the traits using angle bracket notation [x] Disallow user impls of the traits [x] Disallow direct calls to [x] Disallow parenthetical notation () from being used with anything other than the traits In short, we permit unboxed closures to be used as if they are a language builtin, but disallow (for now) a lot of the more generic uses. We should be able to drop this feature gate shortly after 1.0. cc
Nominating for 1.0 or something. :)
P-backcompat-lang, 1.0.
Note that some of this works today though it ought not, e.g. manually implementing traits.
To expand on comment, the following code fails to compile due to the lack of a feature that should be gated: The current solution is to put on the function.
This was done, or done enough.
Oops, I totally overlooked that is still considered legal. It's important to adjust that too!
Change:
<ins> // edition:2021 // issue 108897 trait Handler {} impl<F, Fut> Handler for F where Fut: Send, F: FnOnce() -> Fut, {} fn require_handler<H: Handler>(h: H) {} async fn handler() { let a = &1 as *const i32; async {}.await; } fn main() { require_handler(handler) //~^ ERROR future cannot be sent between threads safely } </ins>

Discussion:
I tried this code: I expected to see this happen: build failed, because this future doesn't implement Send, so this function shouldn't implement Instead, this happened: build pass <!-- 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</detailscargo-bisect-rustc show the Regression in this bug is introduced by this PR <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label: +T-types
I think it's a very serious bug, should we revert this change?
claim
minimized ah, figured out the issue how did you catch this bug?
I try to find the minimized example of there is a ICE with a unsend future in this issue
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Isn't this a stable-to-beta regression since nightly just branched?
Just to clarify since we're in the confusing week where stable & beta are discontinuous version numbers:
Change:
unsafe { self.current = unlinked_node.as_ref().next; self.list.unlink_node(unlinked_node); <del> let unlinked_node = Box::from_raw(unlinked_node.as_ptr()); </del> <ins> let unlinked_node = Box::from_raw_in(unlinked_node.as_ptr(), &self.list.alloc); </ins> Some(unlinked_node.element) } }

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: alloc <addrand dealloc <addris printed Instead, this happened: only alloc <addris printed <!-- 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. --: forgets that it's been initialized with an allocator, and always deletes the node with the global allocator. There seems to be one more place where this happens in the same file. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
let expected = "#![allow(unused)] extern crate hella_qwop; <del> extern crate asdf; </del> <ins> extern crate r#asdf; </ins> fn main() { assert_eq!(asdf::foo, 4); }"

Discussion:
In I tried to create a new testcase that runs doctests. However having the substring in a doctest comment injected an invalid into the code generated for the doctest. Turns out this here is a bit too aggressive: It looks like compiletest actually gave the crate the name , perhaps because it was defined in a file, and having a doctest such as this triggers the this auto-injection, resulting in a failed doctest run: /// // ^ line 10 /// assert_eq!(1, 1); /// `
I think rustdoc needs to check if the crate name is a keyword and add if so. Actually it's probably enough to unconditionally add since it works for things that aren't keywords.
there is actually two bugs here. not being properly escaped is one thing, the other is probably the way that rustdoc is invoked, or not quite sure. Basically it infers the crate name from the file name if not explicitly given, and then just assumes that a crate with that name exists, which it doesn’t.
that's an issue with compiletest, not rustdoc - it needs to compile the crate itself before running rustdoc on it: I don't know how to fix that, I think compiletest needs to add support for this maybe?
Change:
<ins> fn main() { } let _ = (); } //~ ERROR unexpected close delimiter </ins>

Discussion:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.