jiebi/CodeConvo huggingface dataset:
Change:
<ins> error[E0659]: `core` is ambiguous (name vs any other name during import resolution) --> $DIR/issue-57539.rs:4:9 | LL |     use core; //~ ERROR `core` is ambiguous |         ^^^^ ambiguous name | = note: `core` could refer to a built-in extern crate = help: use `::core` to refer to this extern crate unambiguously note: `core` could also refer to the module imported here --> $DIR/issue-57539.rs:5:9 | LL |     use crate::*; |         ^^^^^^^^ = help: use `self::core` to refer to this module unambiguously error: aborting due to previous error For more information about this error, try `rustc --explain E0659`. </ins>

Discussion:
On stable and the code compiles successfully. On the code fails to compile with: At first I thought this was part of but now I think it is different because it started happening on whereas that issue is from November. This is currently causing ggez to fail to compile on nightly:
With uniform paths, which will be in 1.32, this compiles, so this should resolve itself I think. cc
So, this is indeed a regression from Looks like you missed the part, I'm still able to reproduce the error with .
It's not obvious to me right away what behavior is right here, pre- or post-. I'll look in more detail.
The ambiguity is reported correctly. I.e. it's obvious that there's an ambiguity (the error message says what exactly), but before the ambiguity wasn't detected due to "self-confirming" import "standing in the way". It's great that the fix got into 1.32 stable, so the time for which the issue existed on stable was minimized. Minimized reproduction:
Test in
Change:
cmd = m.group('cmd') args = m.group('args') if args and not args[:1].isspace(): <del> raise RuntimeError('Invalid template syntax at line {}'.format(lineno+1)) </del> <ins> print_err(lineno, line, 'Invalid template syntax') continue </ins> args = shlex.split(args) <del> yield Command(negated=negated, cmd=cmd, args=args, lineno=lineno+1) </del> <ins> yield Command(negated=negated, cmd=cmd, args=args, lineno=lineno+1, context=line) </ins> def _flatten(node, acc):

Discussion:
When a doc test fails, the console output looks like this: A traceback should only be shown if there was an error in the python script itself - in this case it should only show the matches error, something like this:
cc me. I'm surely willing to fix that as soon as I get enough spare time.
did you ever get a chance to look at this? (Do you know if the situation has changed?)
No, also I'm not aware of any update. Looks like that I've forgotten this at that time (as flt2dec was being matured); I have virtually no energy to contribute nowadays, so I probably cannot work on this right now.
Change:
let span_start = self.token.span; let ast::FnHeader { ext, unsafety, constness, asyncness } = self.parse_fn_front_matter(&inherited_vis)?; <ins> if self.may_recover() && self.token.kind == TokenKind::Lt { self.recover_fn_ptr_with_generics(lo, &mut params, param_insertion_point)?; } </ins> let decl = self.parse_fn_decl(|_| false, AllowPlus::No, recover_return_sign)?; let whole_span = lo.to(self.prev_token.span); if let ast::Const::Yes(span) = constness {

Discussion:
Newcomers might attempt to write a “generic” function pointer like . In such case, the compiler should provide a better error message. Inspired by a recent Reddit thread I sadly cannot find anymore. Given the following code: The compiler should mention that function pointers may not be generic or […] may not have generic parameters, suggest to move the lifetime(s) to a parameter list (this should be machine-applicable in my judgement) and be able to recover: For later reference, the current output is: Given the following code: The compiler should mention that function pointers may not be generic or […] may not have generic parameters and be able to recover emitting two diagnostics, one for each line. The compiler could also suggest moving the generic parameter list further up to the owning function, struct, etc. if available. Note that this might not be what the user intended (since there is a semantic difference between hypothetical higher-ranked generics and normal ones) and therefore shouldn't be machine-applicable. For later reference, the current output is: label A-parser A-suggestion-diagnostics D-newcomer-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> macro_rules! make_item { ($a:ident) => { struct $a; }; //~^ ERROR expected expression //~| ERROR expected expression } fn a() { make_item!(A) } fn b() { make_item!(B) } fn main() {} </ins>

Discussion:
This is a regression from stable to beta and nightly. This code is wrong (missing semicolons): Stable prints: Beta and nightly both print: Notice that not only is all the useful information gone, but the compiler aborts after the first error instead of finding the rest. It does not matter whether is on or off. cc
cc me
So this fell through the cracks, and was a stable to nightly/beta regression. It still is a regression, in a way, but only of diagnostics. Could you take a look?
Nominating for prioritization.
So this part of the (previous) stable message: feels like a bug to me anyhow. This part: is sort of good. It'd be nice to preserve a backtrace, at least. And ideally we'd suggest adding a .
Given how much time has past, we're going to call this P-medium for now. However, will try to write up some mentoring instructions (or maybe fix it). He has a plan. =) triage: P-medium
I think the best path forward here is to try parsing an expression macro expansion as a statement before emitting an error. If the macro expansion parses as a statement successfully, we can emit a more helpful error suggesting that the user add a semicolon to the macro invocation.
I'm interested in this but I need informations to understand what to do :)
Current output:
Diagnostics meeting triage: lowering priority as the current error is pretty good, even if not ideal yet.
Current output: (Notice that we recover -- it's not a fatal error now.)
Change:
} #[test] <ins> fn test_into_keys() { let vec = vec![(1, 'a'), (2, 'b'), (3, 'c')]; let map: HashMap<_, _> = vec.into_iter().collect(); let keys: Vec<_> = map.into_keys().collect(); assert_eq!(keys.len(), 3); assert!(keys.contains(&1)); assert!(keys.contains(&2)); assert!(keys.contains(&3)); } #[test] fn test_into_values() { let vec = vec![(1, 'a'), (2, 'b'), (3, 'c')]; let map: HashMap<_, _> = vec.into_iter().collect(); let values: Vec<_> = map.into_values().collect(); assert_eq!(values.len(), 3); assert!(values.contains(&'a')); assert!(values.contains(&'b')); assert!(values.contains(&'c')); } #[test] </ins> fn test_find() { let mut m = HashMap::new(); assert!(m.get(&1).is_none());

Discussion:
Associative maps ( and ) in Rust are currently missing two methods to get owning iterators to their keys or values. We have to get key-value reference pairs, to get key-value mutable reference pairs and to get owned key-value pairs. I'd expect and to offer a similar trio of methods (with an exception for of course). is there, but the variants are missing for seemingly no good reason. As an example implementation (but perhaps we can do better):
I would accept a PR to introduce unstable intokeys() and intovalues().
Hi, I’m interested in working on this but I have a question regarding the implementation. I guess we can implement this in two ways. First one is implementing like the example in the first comment, like returning . And the second option is to return a struct of its own (like a mixture of and / structs) instead of returning . We can name them IntoKeys and IntoValues and they can be responsible of implementing the trait. I feel like performance wise they are same, since map and custom struct both will be evaluated lazily when we iterate over. But there might be a rule to always return a proper type in the rust std code that I don't know. So I think I’m okay implementing either way but wanted to ask just in case. What do you think?
For the public API I would prefer this implemented using dedicated IntoKeys and IntoValues iterator types. They can be implemented internally as wrappers around Map<IntoIter<K, Vif that simplifies things.
Thanks for the answer Created a PR for this and you as a reviewer. Would you mind taking a look at it when you have time?
Change:
} else { let mut diag = cx.ecx.struct_span_err(cx.fmtsp, "multiple unused formatting arguments"); <del> for (sp, msg) in errs { diag.span_note(sp, msg); </del> <ins> // Ignoring message, as it gets repetitive // Then use MultiSpan to not clutter up errors for (sp, _) in errs { diag.span_label(sp, "unused"); </ins> } diag } };

Discussion:
After , the output for errors looks like: that's a lot of lines dedicated to underlining macro acruments. They should all be output in one multispan. cc
Hum indeed. If no one has taken it in 12 hours, I'll give it a look.
I'm poking at it right now. I think I need to fix 's methods to accept instead of just , and then I can use directly. After all, I created the problem, I should probably fix it. :P
Perfect. Good luck! :)
I believe this should be closed.
Hold on, it seems the PR is still open.
Seeing as there isn’t anyone working on this anymore, I’ll be happy to take over. This is my first issue, (woot), so I’m not exactly sure where to start. I assume I should just fork the repo, change to use , and fix the tests? Pinging and in case you want to work on this still.
I am not working on this anymore.
Those steps may be correct; or someone else may be able to verify for you. You can also look at and which appear to be previous PRs which attempted to do this. Let us know if you'd like any help!
Awesome! I'm super excited. Anyone specific I should ?
bors will select someone automatically if you don't specify anyone, but I think any of me, or would be available for review and or guidance.
For some reason I seem to be getting unrelated to my changes. (ran )
Those tests shouldn't actually be running in ... cc For these changes, I would suggest , I think that should be enough.
Gotcha, it’s possible I copy pasted from the wrong command (on mobile can’t check right now), but I’ll use that command for testing and see if it works. I’m kinda busy for the rest of the week but I’ll keep working on it in my free time. I’ll comment here until I get a PR ready with any updates I have.
Change:
Canonical, CanonicalQueryResponse, CanonicalVarValues, QueryResponse, }; use rustc_infer::infer::outlives::env::OutlivesEnvironment; <del> use rustc_infer::infer::{DefineOpaqueTypes, InferCtxt, InferOk, RegionResolutionError}; </del> <ins> use rustc_infer::infer::{DefineOpaqueTypes, InferCtxt, InferOk, RegionResolutionError, TypeTrace}; </ins> use rustc_macros::extension; use rustc_middle::arena::ArenaAllocatable; use rustc_middle::traits::query::NoSolution; use rustc_middle::ty::error::TypeError; use rustc_middle::ty::{self, Ty, TyCtxt, TypeFoldable, Upcast, Variance}; <ins> use rustc_type_ir::relate::Relate; </ins> use super::{FromSolverError, FulfillmentContext, ScrubbedTraitError, TraitEngine}; use crate::error_reporting::InferCtxtErrorExt;

Discussion:
I believe this is caused by . Does that look like anything to you? This doesn't seem to happen with the dist artifacts, only the settings used when testing in CI. The config used in CI is: EDIT: Almost certainly since it comes from . This is causing the reference test suite to fail. Using which is currently unreleased.
Yeah, it's a debug assertion after all. I'll look into it and relax the assertion
Change:
#![feature(box_syntax)] #![feature(cell_update)] <del> #![feature(copied)] </del> #![feature(core_private_bignum)] #![feature(core_private_diy_float)] #![feature(dec2flt)]

Discussion:
This is a tracking issue for . Added in . Feature gate: . Related feature: in .
Did you mean in the first sentence?
Fixed.
The lint in Clippy should be updated to suggest this instead when the type is copiable.
So we a newtype because that's what we usually do. However, in this case, we could simply reuse and implement copied as: Are there notable reasons not to do this that I'm missing? Doing so would substantially decrease the cost of this feature for the standard library.
type wouldn't have the guarantees that does, as it calls the method, which can have side-effects (it shouldn't, but it's not something we can depend on). Although I suppose we currently DO expose specialization in structure when implementation is incompatible with implementation. This seems like a bug, so I will fix that in a separate PR.
See .
The comment about the type belongs in Since I see no objection to : fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.
Am I correct that this now awaits for a stabilization PR?
Yes.
Stabilization PR is up:
Change:
} } <ins> // Format a number with thousands separators fn fmt_thousands_sep(mut n: usize, sep: char) -> String { use std::fmt::Write; let mut output = String::new(); let mut first = true; for &pow in &[9, 6, 3, 0] { let base = 10_usize.pow(pow); if pow == 0 || n / base != 0 { if first { output.write_fmt(format_args!("{}", n / base)).unwrap(); } else { output.write_fmt(format_args!("{:03}", n / base)).unwrap(); } if pow != 0 { output.push(sep); } first = false; } n %= base; } output } </ins> pub fn fmt_bench_samples(bs: &BenchSamples) -> String { <ins> use std::fmt::Write; let mut output = String::new(); let median = bs.ns_iter_summ.median as usize; let deviation = (bs.ns_iter_summ.max - bs.ns_iter_summ.min) as usize; output.write_fmt(format_args!("{:>11} ns/iter (+/- {})", fmt_thousands_sep(median, ','), fmt_thousands_sep(deviation, ','))).unwrap(); </ins> if bs.mb_s != 0 { <del> format!("{:>9} ns/iter (+/- {}) = {} MB/s", bs.ns_iter_summ.median as usize, (bs.ns_iter_summ.max - bs.ns_iter_summ.min) as usize, bs.mb_s) } else { format!("{:>9} ns/iter (+/- {})", bs.ns_iter_summ.median as usize, (bs.ns_iter_summ.max - bs.ns_iter_summ.min) as usize) </del> <ins> output.write_fmt(format_args!(" = {} MB/s", bs.mb_s)).unwrap(); </ins> } <ins> output </ins> } // A simple console test runner

Discussion:
From , (I assume identical to ) should report nanosecond times as or , not . This reportedly would require fixing in libtest.
I posted a PR for this yesterday. Well I chose to round & use units, but you can opine either way
nice! If you'll just tag that as fixing this then bors will take care of the rest.
Change:
<ins> // check-fail // edition:2021 // test for issue-114912 - debug ice: attempted to add with overflow async fn main() { //~^ ERROR `main` function is not allowed to be `async` [0usize; 0xffff_ffff_ffff_ffff].await; //~^ ERROR `[usize; usize::MAX]` is not a future } </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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I have no idea why this exists, nor does removing it change test output. Someone should find out what it's for, and also add tests around this code ideally.
claim
Reason add 1 to 0 is to match the "pluralize" macro. In the macro, if x is not 1 (more than 1), then append "s" (indicating as plural). If x is 1, then append nothing. Thus satisfy the "pluralize" macro.
claim
Ok looks like this can be closed because the solution was merged in
claim
Hello, I see someone else already assigned, but this issue is still "open" and has the "help wanted" tags. I'm new to contributing to Rust, so if you're willing to help, I'd be happy to help. Thanks!
Hi David, Apekros has already posted a PR for this one: which has not been merged yet however.
Change:
<ins> error: `&dyn PartialEq<u32>` cannot be used in patterns --> $DIR/issue-72565.rs:6:9 | LL |         F => panic!(), |         ^ error: aborting due to previous error </ins>

Discussion:
Compiled with: Using: Gives:
The problem is not tied to box:
No longer ICEs after
Ops, sorry, I reopen until a test is present.

: <details<summary<strongBacktrace</strong</summary<p</p</detailssearched nightlies: from nightly-2019-10-03 to nightly-2020-07-05 regressed nightly: nightly-2020-02-16 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
Minified, It seems possible to ICE on stable, though I'm not sure if it counts? <details<summaryStable error</summary</details
The ICE is fixed in the latest nightly, marking as .
Change:
<ins> error: `&dyn PartialEq<u32>` cannot be used in patterns --> $DIR/issue-72565.rs:6:9 | LL |         F => panic!(), |         ^ error: aborting due to previous error </ins>

Discussion:
This produces an ICE (): It points to this assert firing: This assert assumes that if we match on a with a const, then must be . I'm not sure where this assumption comes from (I'd guess byte-array patterns), but it's clearly wrong. Note that this also fails with any other non- type here instead of . Note that this does not fail when the arrays are not behind references, or if we use slices instead of arrays. EDIT: removed unnecessary feature gate
The feature gate isn't needed to trigger the ICE
Oh, well spotted. And it appears that fails on stable too then
cc as it's possible this is related to your structural match work I guess?
Funny enough: this doesn't ICE but instead shows the correct "unreachable" warning
Reduced:
What the heck?!?
triage: P-high. Removing nomination. Self-assigning.
That's a leftover from matching on byte strings, which used to be one of the few constants one could actually match on.
I think it's one more of theses cases where we don't know how to handle properly. shouldn't even exist: specialization should be able to specialize consts by unpacking a pattern into its subpatterns, like we specialize everything else.
I've figured out a way to eliminate the ICE, but I do not think my code has the desired semantics. That is, I would imagine we would want this to be accepted: but my current draft code rejects the above as non-exhaustive. On the other hand, that does match the current behavior of the compiler, for better or for worse. Update: Or maybe I've forgotten the desirata for how match usefulness and consts are supposed to interact...?
This was not a stable reduction; on the current nightly, the above length-zero ZST array is accepted with no ICE, while the original length-one ZST array still causes an ICE.
Yet another fun variation on the test: yields:
The reason it exists is that we don't want to unpack a multi megabyte byte string you may have gotten from . That would be super inefficient and likely just cause an out of memory abort. The reason why I believe we should also do this optimization for other types is that you can easily transmute a multi megabyte byte string to another array type in a constant, and then you have the same problem all over again.

(Or you init with a repeat expression). I agree that it would be nicer and less fragilr if we just unpacked everything.
Btw, addresses a few of the ICEs around this
Since the original and reduced versions no longer ICE, but still does
The above no longer ICEs after , could do with a test
Change:
)); } <del> let needs_parens = match expr.kind { // parenthesize if needed (Issue #46756) hir::ExprKind::Cast(_, _) | hir::ExprKind::Binary(_, _, _) => true, // parenthesize borrows of range literals (Issue #54505) _ if is_range_literal(expr) => true, _ => false, }; </del> if let Some((sugg, msg)) = self.can_use_as_ref(expr) { return Some(( sugg,

Discussion:
What I actually wanted was . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The problem is by the time this error is emittedwe don't have the information about the root cause anymore. In this case that would be the type of being checked for and figuring out the the rhs needs to be of the same type. Clippy has a lint that will tell you to clean it up afterwards, but we should probably issue a better diagnostic to begin with.
can you please create a ?
Please excuse my naïvety, but why is this (according to csmoes MCVE) a problem? You can actually write if i < &0 {} and everything works just fine. Can you please explain this part (to me)?
The comparison operator already takes references to both sides. so it seems simpler to dereference the lhs and save the monomorphizer and the optimizer some effort
Resurrecting this. what're the benefits of dereferencing the lhs instead of referencing the rhs? Also, if I were to go about fixing this, where would I start?
The benefit is that expands to , so if you start out with you get , seems better to just do instead (since is a no-op that gets easily removed). I'm not sure how to solve this or whether we should try at all.
claim
I want to get started with this, but would appreciate some mentoring from someone before I do, to point me in the right direction please
There's a reason I marked this as . I have no idea how to do this reasonably. I'm sorry, but I have no hints for you, and I don't even know if it's possible to do in a reasonable way.
cue terminator background music Leaving this here for future generations to see. I'm gonna try attempting to solve this and see if I can do something about it. I don't know if I can, or if I'll even survive this, but there's only one way to find out. Lol in all seriousness, if someone wants to claim this up, feel free to. Until then, I'll try and fix this.
Hi, are you still working on this issue
Hey I've been meaning to fix this up.

I've reached a point where I know exactly how to fix this as well. I just haven't found the time to fix this. Feel free to take it up, considering I wouldn't be having the time to work on this in the forseeable future.
release-assignment If do you find the time in the future, please claim this issue again. Until then I'll free it up in case anybody else wants it
Is anyone currently working on this? If not, I'd be happy to give it a go. claim