jiebi/CodeConvo huggingface dataset:
Change:
warning: not reporting region error due to nll <del> --> $DIR/issue-45983.rs:17:27 </del> <ins> --> $DIR/issue-45983.rs:36:27 </ins> | LL |     give_any(|y| x = Some(y)); |                           ^ error: borrowed data escapes outside of closure <del> --> $DIR/issue-45983.rs:17:18 </del> <ins> --> $DIR/issue-45983.rs:36:18 </ins> | LL |     let x = None; |         - `x` is declared here, outside of the closure body

Discussion:
D'oh: while investigating , I found a case where we are downgrading the NLL errors to warnings (due to the migration mode in ), but AST-borrowck issues an error for the test! (This may explain , at least in part...) Namely, . Here is the test: Here is the AST-borrowck output (a hard error): And here is the NLL output (another hard error): But here is the output from : ui/borrowck/issue- is one particular instance of this, but now that I've found one, I'm certain there are more. This is pretty bad. Very high priority to fix.
This code looks suspicious:
Ha I should have just left this to to fix, since we seem to have independently identified the culprit.
I think I've already assigned myself to enough issues.
Change:
self.parse_block_expr(label, lo, BlockCheckMode::Default, attrs) } else if !ate_colon && (self.check(&TokenKind::Comma) || self.check(&TokenKind::Gt)) { // We're probably inside of a `Path<'a>` that needs a turbofish, so suppress the <del> // "must be followed by a colon" error. </del> <ins> // "must be followed by a colon" error, and the "expected one of" error. </ins> self.diagnostic().delay_span_bug(lo, "this label wasn't parsed correctly"); consume_colon = false; Ok(self.mk_expr_err(lo))

Discussion:
Reproducible at . <details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Seems to be introduced in :
Thanks for the report! A compiler panic is probably best reported in rust-lang/rust, even though it's being surfaced by a dev tool. I'll check with infra to see if it makes sense to move the issue We actually haven't made any changes to rustfmt in that window and the were highly minimal and certainly don't strike me as anything that would be the root cause. As such I suspect this is due to changes made elsewhere within the compiler mods, and would at least like for those folks to be aware (even if we need to make changes on the rustfmt side to address/work around) Would you be up for trying to boil it down to a more simple repro case?
Sure! Here is a MRE:
I have bisected to . cc I noticed that rustfmt is exiting with 0 even though it panicked. Is that normal?
I'll look into it today or tomorrow! claim
Outside a macro, no, (as was the case in the original full repro), but yes within the context of a macro as in the minimal rerpo. We have our calls to rustcparse internals wrapped in so the panic isn't really surfacing here, but rustfmt is still displaying the underlying error text prior to emitting formatting. This is done partly due to the fact that there are scenarios where those internals panic that we want to wrap to an error type, and partly due to there being some scenarios we want to ignore for the purposes of formatting due to how we attempt to deal with macros in the pre-expansion world where rustfmt lives. The latter being a result of limited macro support and leaving macros it can't handle alone, while carrying on formatting the rest of the file/crate/workspace
It looks like I'm still getting this error with (Coming from that was closed due to this one) Playground seems to produce it also:
I'll take another look then.
Yeah, this continues to ICE even in rustc. Fixed in another PR.
Change:
} #[cfg(not(no_global_oom_handling))] <ins> #[stable(feature = "vec_from_array_ref", since = "CURRENT_RUSTC_VERSION")] impl<T: Clone, const N: usize> From<&[T; N]> for Vec<T> { /// Allocate a `Vec<T>` and fill it by cloning `s`'s items. /// /// # Examples /// /// ``` /// assert_eq!(Vec::from(&[1, 2, 3]), vec![1, 2, 3]); /// ``` fn from(s: &[T; N]) -> Vec<T> { Self::from(s.as_slice()) } } #[cfg(not(no_global_oom_handling))] #[stable(feature = "vec_from_array_ref", since = "CURRENT_RUSTC_VERSION")] impl<T: Clone, const N: usize> From<&mut [T; N]> for Vec<T> { /// Allocate a `Vec<T>` and fill it by cloning `s`'s items. /// /// # Examples /// /// ``` /// assert_eq!(Vec::from(&mut [1, 2, 3]), vec![1, 2, 3]); /// ``` fn from(s: &mut [T; N]) -> Vec<T> { Self::from(s.as_mut_slice()) } } #[cfg(not(no_global_oom_handling))] </ins> #[stable(feature = "vec_from_array", since = "1.44.0")] impl<T, const N: usize> From<[T; N]> for Vec<T> { /// Allocate a `Vec<T>` and move `s`'s items into it.

Discussion:
Currently we have , should and also be implemented for where ? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Can you help me with runnable code to understand why the will be useful and what can be a use case for it? label +T-libs-api
Ah ok, maybe I understand what do you mean, currently we can do And your proposal is to support
I don’t have a use case for , adding it is just for matching existing . But for , I want to be able to write: instead of
Change:
MatchIndices { haystack: *self, needle: sep, <del> position: 0 </del> <ins> searcher: Searcher::new(self.as_bytes(), sep.as_bytes()) </ins> } }

Discussion:
The current implement of functions like are naive string searches, not using a more intelligent algorithm like Boyer-Moore (with a comment referring one to ). Unfortunately that means we're trounced when performing operations like that. e.g. glibc's : and A cursory search found which might be interesting to experiment with. came up on
This is for the case where the needle is a single character. In the case above the rust version is as fast or faster than the C version. Maybe there is a bug in the case for short needles.
Change:
#[unsafe_destructor] impl<K, V> Drop for RawTable<K, V> { fn drop(&mut self) { <del> if self.hashes.0.is_null() { </del> <ins> if self.hashes.is_null() { </ins> return; } // This is done in reverse because we've likely partially taken

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:
<ins> error[E0282]: type annotations needed --> $DIR/issue-65611.rs:59:20 | LL |     let x = buffer.last().unwrap().0.clone(); |                    ^^^^ cannot infer type for `T` | = note: type must be known at this point error[E0609]: no field `0` on type `&_` --> $DIR/issue-65611.rs:59:36 | LL |     let x = buffer.last().unwrap().0.clone(); |                                    ^ error: aborting due to 2 previous errors Some errors have detailed explanations: E0282, E0609. For more information about an error, try `rustc --explain E0282`. </ins>

Discussion:
The compiler correctly errors about the ambiguous types, but also panics on this code:
Also reproduces on nightly. Panic happens here:
triage: P-medium. removing nomination label. reasoning: has a PR. tagging as P-medium (since it does produce useful error message before ICE'ing), and removing nomination label.
Change:
use extra::sort; use syntax::ast; <ins> use syntax::attr; </ins> use clean; use doctree;

Discussion:
Nominating for milestone 5, production-ready
Can't be done without running resolve.
should be optional at most, as sometimes you want to see them
just a bug, removing milestone/nomination.
Still relevant though parenting to metabug on rustdoc_ng
/cc This would involve looking at the visibility of the associated trait and excluding the impl from the list if it's not public.
Didn't find a trait to test it with but it should be done now.
Change:
config.keep_stage = flags.keep_stage; config.keep_stage_std = flags.keep_stage_std; config.color = flags.color; <ins> config.free_args = flags.free_args.clone().unwrap_or_default(); </ins> if let Some(value) = flags.deny_warnings { config.deny_warnings = value; }

Discussion:
Right now, x.py is pretty inconsistent with cargo's CLI. To pass arguments to compiletest, you use ; to pass arguments to you use ; to pass arguments to cargo you use CARGOFLAGS. I would like to unify these with the same syntax as cargo: would behave the same as today would behave the same as would behave the same as today, except that it would only pass it to cargo commands invoked by bootstrap, not when building bootstrap itself (avoiding the "argument --fix-broken not expected" error you'd get today). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Looking at the current setup for argument parsing, it appears that getopts::Options struct doesn't have a state engine based parser, so it wont be able to parse -- as a state changing flag. I'm thinking probably parse and translate the args in python then just pass it on to the bootstrap executable, (unless someone here has a better idea).
let's not put any logic in python if we can help it, it's going away soon: . I think it would be ok to switch to or another arg parser if it makes things easier.
Ah, I was thinking something like getting rid of the python script was going to happen someday. will probably do for the functionality we will need from it.
I'm out of town for the rest of the week so if anyone would like to take this issue while I'm away, go for it.
Change:
visit::walk_expr(self, expr); } <del> fn visit_fn(&mut self, fn_kind: visit::FnKind<'v>, decl: &'v ast::FnDecl, block: &'v ast::Block, span: Span, _id: ast::NodeId) { match fn_kind { visit::FkItemFn(..) | visit::FkMethod(..) => { // ignore nested fn items } visit::FkFnBlock => { visit::walk_fn(self, fn_kind, decl, block, span); } } } </del> <ins> // Skip all items; they aren't in the same context. fn visit_item(&mut self, _: &'v ast::Item) { } </ins> } impl<'a,'tcx> SeedBorrowKind<'a,'tcx> {

Discussion:
Doesn't seem to ICE as of rustc 1.4.0-beta.3 ( 2015-10-16)
Yes, it's fixed, and there's a testcase in the tree; I just forgot to close it.
Change:
<ins> // Test that we catch that the reference outlives the referent and we // successfully emit a diagnostic. Regression test for issue #114714. #![feature(generic_const_items)] #![allow(incomplete_features)] const Q<'a, 'b>: &'a &'b () = &&(); //~ ERROR reference has a longer lifetime than the data it references fn main() {} </ins>

Discussion:
The code below leads to the following compiler panic <details<summaryfull stderr</summary</details<details<summary<coderustc -Vv</code</summary</details label -needs-triage C-bug I-ICE T-compiler F-genericconstitems requires-incomplete-features claim <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Minimized:
Change:
<ins> error[E0277]: the trait bound `T: Bar<N>` is not satisfied --> $DIR/ct-var-in-collect_all_mismatches.rs:9:14 | LL |         self.unsatisfied() |              ^^^^^^^^^^^ the trait `Bar<N>` is not implemented for `T` | note: required by a bound in `Foo::<T, N>::unsatisfied` --> $DIR/ct-var-in-collect_all_mismatches.rs:15:12 | LL |     fn unsatisfied(self) |        ----------- required by a bound in this LL |     where LL |         T: Bar<N>, |            ^^^^^^ required by this bound in `Foo::<T, N>::unsatisfied` help: consider restricting type parameter `T` | LL | impl<T: Bar<N>, const N: usize> Foo<T, N> { |       ++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
Regression from stable 1.66 / beta 1.67 -nightly 1.68 (haven't bisected). Stable/beta correctly produce an error, nightly ICEs. I've also confirmed the behavior on the latest commit to master (, at time of writing). (nightly — ICE) (beta — error as expected) (stable — error as expected) Setting produced the same output as above. I tried to dig into this, struggled to make sense of the typechecking code. I think the following is going on: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cargo-bisect-rustc seems to think this is caused by of which looks like the most plausible candidate since it touched type relation code which calls without handling infer vars :thinking: cc
Ugh i'll fix it claim
WG-prioritization assigning priority (). label -I-prioritize +P-high
This is a bit weird, but I was able to come up with an alternative reduction (after hit it on - we use a pinned nightly so this is mostly a coincidence): I'm not sure why the inference variable vs generic param makes a difference like that, but I wasn't able to combine the two reductions together. Also, the ICE query stack confirms the / split between nightly versions, even in the combined example.
Change:
#![allow(dead_code)] <ins> use crate::sync::IntoDynSyncSend; use crate::FatalErrorMarker; </ins> use parking_lot::Mutex; use std::any::Any; use std::panic::{catch_unwind, resume_unwind, AssertUnwindSafe};

Discussion:
found while checking with When you run the snipped above with , rustc panics, but the exit status is as if there was just a normal compiler error, instead of a . This tripped up automatic ice-reduction that relies on a somewhat familiar exit code when the program crashes :sweat_smile:
is the problematic line here that turns ICEs into "normal" fatal errors that call exit(1) though actually at least with the non parallel compiler i'm very surprised that we're ending up in a query in the first place after panicking.
It seems that current stable does correctly exit with here... I bisected the exit code 101 -exit code 1 change with a crashing file ( ) and got to Regression in nightly-2023-08-31 Regression in cc /
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
} } <ins> // We get all the associated items that _are_ set, // so that we can check if any of their names match one of the ones we are missing. // This would mean that they are shadowing the associated type we are missing, // and we can then use their span to indicate this to the user. let bound_names = trait_bounds .iter() .filter_map(|poly_trait_ref| { let path = poly_trait_ref.trait_ref.path.segments.last()?; let args = path.args?; Some(args.bindings.iter().filter_map(|binding| { let ident = binding.ident; let trait_def = path.res.def_id(); let assoc_item = tcx.associated_items(trait_def).find_by_name_and_kind( tcx, ident, AssocKind::Type, trait_def, ); Some((ident.name, assoc_item?)) })) }) .flatten() .collect::<FxHashMap<Symbol, &AssocItem>>(); </ins> let mut names = names .into_iter() .map(|(trait_, mut assocs)| {

Discussion:
Given the following code: The current output is: is wrong, specifying another isn't going to fix the problem. Writing just has a suggestion where`, which is good, but the concrete syntax would be nice. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We probably should modify E0191 to hint that an supertrait's associated type is shadowed. I think E0719 here is fine to keep as-is, imo.
I agree the message for E0719 is good as-is.
Is this issue fixed ? If not can I take this up, please. Also how exactly should E0191 be modified. Imo, I don't think E0191 should pop up in this case as E0719 conveys the message.
claim
claim
Ask for help How do I specify the association type of supertrait with the same name? In other words, is there an easy way to modify the code in the issue to make it pass compilation? Here's my clumsy way of creating a new trait.
Is this issue still open? If so I would like to take a crack at it.
If you can still reproduce it, then yes indeed. assign
Error: Parsing assign command in failed: ...'zyDutchman' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I have now a hint about the shadowing: But I am not quite sure about what to do about the actual message. Do we want to suggest renaming to something else Or do we want to suggest the work-around by
If the trait is local, then we could suggest renaming it. It's not required to be super specific here--we could just note the conflict to make the user aware of it, for example.
I have updated the help message so that this case: gives this error message: The rename help message is emitted for both the super trait and the subtrait, if they are local. I think I am ready to make a merge request, or does somebody have something else to add?
I recommend you to just open a PR. Any further discussions can happen over there :)
Change:
(use_span, "'_".to_owned()) }; debug!(?deletion_span, ?use_span); <ins> // issue 107998 for the case such as a wrong function pointer type // `deletion_span` is empty and there is no need to report lifetime uses here let suggestions = if deletion_span.is_empty() { vec![(use_span, replace_lt)] } else { vec![(deletion_span, String::new()), (use_span, replace_lt)] }; </ins> db.multipart_suggestion( msg, <del> vec![(deletion_span, String::new()), (use_span, replace_lt)], </del> <ins> suggestions, </ins> Applicability::MachineApplicable, ); }

Discussion:
<!-- 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. --: Needs a rustc built with debug assertions, <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Change:
/// Returns `true` if `def_id` refers to a definition that does not have its own /// type-checking context, i.e. closure, coroutine or inline const. pub fn is_typeck_child(self, def_id: DefId) -> bool { <del> matches!(self.def_kind(def_id), DefKind::Closure | DefKind::InlineConst) </del> <ins> matches!( self.def_kind(def_id), DefKind::Closure | DefKind::InlineConst | DefKind::SyntheticCoroutineBody ) </ins> } /// Returns `true` if `def_id` refers to a trait (i.e., `trait Foo { ... }`).

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
Change:
<ins> //@ run-rustfix #![allow(unreachable_code, dead_code)] fn main() { fn mismatch_types1() -> i32 { match 1 { x => return dbg!(x), //~ ERROR mismatched types } todo!() } fn mismatch_types2() -> i32 { match 2 { x => { return dbg!(x) //~ ERROR mismatched types } } todo!() } fn mismatch_types3() -> i32 { match 1 { _ => return dbg!(1) //~ ERROR mismatched types } todo!() } fn mismatch_types4() -> i32 { match 1 { _ => {return dbg!(1)} //~ ERROR mismatched types } todo!() } } </ins>

Discussion:
when using i even got this suggestion recommending i return DefKind from the GlobalCtxt::enter closure, which isn't even remotely the right type. it also seems to only show up when using macros? all around quite strange. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
// Check whether the self-type is itself a projection. // If so, extract what we know from the trait and try to come up with a good answer. let bounds = match *obligation.predicate.self_ty().kind() { <del> ty::Alias(_, ref data) => tcx.item_bounds(data.def_id).subst(tcx, data.substs), </del> <ins> // Excluding IATs here as they don't have meaningful item bounds. ty::Alias(ty::Projection | ty::Opaque, ref data) => { tcx.item_bounds(data.def_id).subst(tcx, data.substs) } </ins> ty::Infer(ty::TyVar(_)) => { // If the self-type is an inference variable, then it MAY wind up // being a projected type, so induce an ambiguity.

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This might also be related to cc
label F-inherentassociatedtypes claim
Change:
} } <ins> #[stable(feature = "mpsc_debug", since = "1.7.0")] impl<T> fmt::Debug for Sender<T> { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { write!(f, "Sender {{ .. }}") } } </ins> //////////////////////////////////////////////////////////////////////////////// // SyncSender ////////////////////////////////////////////////////////////////////////////////

Discussion:
All public types should implement Debug. Per conversation on #rust-internals, there might be some useful information that could be printed for these types -- but even just "Sender { .. }" etc. would be a start.
Was this
probably. It has been suggested that way more useful info could actually be printed instead of the opaque placeholders -- but that would be more of a wishlist item than a bug... The patch is sufficient to fix the actual problem I was running into: not being able to #[derive(Debug)] on any structure containing mpsc Senders/Receivers.
Ok, closing.
Change:
{ let predicate = infcx.resolve_type_vars_if_possible(&obligation.predicate); <del> if !predicate.references_error() { </del> <ins> // The ty_err created by normalize_to_error can end up being unified // into all obligations: for example, if our obligation is something // like `$X = <() as Foo<$X>>::Out` and () does not implement Foo<_>, // then $X will be unified with ty_err, but the error still needs to be // reported. if !infcx.tcx.sess.has_errors() || !predicate.references_error() { </ins> span_err!(infcx.tcx.sess, obligation.cause.span, E0271, "type mismatch resolving `{}`: {}", predicate.user_string(infcx.tcx),

Discussion:
Hello folks, I'm dutifully reporting this as the compiler told me to so. The bug is the same reported already by and , although it appeared on a different circumstance. I have this simple program (I'm a Rust newbie so It's very likely I'm doing things terribly wrong): Expected outcome: The compile to tell me how wrong I am Actual outcome: Meta Shows up with latest beta as well:
cc me
Minified: We do write tyerr to node 11 (). Apparently we somehow don't report an error.
triage: P-medium
Whoops. There is indeed an error, which is indeed gets to reportselectionerror, but when we do (), we get an error, and think this one was a duplicate.
no_std version:
You don't even need the trait: