jiebi/CodeConvo huggingface dataset:
Change:
<ins> use std::fmt; struct S { } impl S { fn hello<P>(&self, val: &P) where P: fmt::Display; { //~^ ERROR non-item in item list //~| ERROR associated function in `impl` without body println!("val: {}", val); } } impl S { fn hello_empty<P>(&self, val: &P) where P: fmt::Display; //~^ ERROR associated function in `impl` without body } fn main() { let s = S{}; s.hello(&32); } </ins>

Discussion:
When copying bounds from a trait assoc item, you can accidentally copy the semicolon. If you forget to remove it, multiple errors are emitted, while the second is: This should be explicitly handled to avoid knock down errors. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> error[E0412]: cannot find type `e` in this scope --> $DIR/issue-91267.rs:2:16 | LL |     0: u8<e<5>=e> |                ^ |                | |                not found in this scope |                help: maybe you meant to write an assignment here: `let e` error[E0229]: associated type bindings are not allowed here --> $DIR/issue-91267.rs:2:11 | LL |     0: u8<e<5>=e> |           ^^^^^^ associated type not allowed here error[E0308]: mismatched types --> $DIR/issue-91267.rs:2:5 | LL | fn main() { |           - expected `()` because of default return type LL |     0: u8<e<5>=e> |     ^^^^^^^^^^^^^ expected `()`, found `u8` error: aborting due to 3 previous errors Some errors have detailed explanations: E0229, E0308, E0412. For more information about an error, try `rustc --explain E0229`. </ins>

Discussion:
I'm seeing an internal compiler error on the following input, found by : The ICE happens after correctly reporting another error, so low priority. Affected versions: I tried nightly 2021-11-25 and stable 1.56.1 and they both show the same ICE. <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I will give this a try claim
Change:
<ins> // edition:2021 // run-pass fn solve<F>(validate: F) -> Option<u64> where F: Fn(&mut [i8; 1]), { let mut position: [i8; 1] = [1]; Some(0).map(|_| { validate(&mut position); let [_x] = position; 0 }) } fn main() { solve(|_| ()); } </ins>

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: The code should compile. Instead, this happened: This compiler error is thrown: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: (also works on stable 1.54). Starting from , I get the error shown above. <!-- Provide the version you are using that has the regression. --: current nightly Also broken on 1.55 beta 7: Both installed via rustup. <!-- Did the compiler crash? If so, please provide a backtrace. --n/a <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --This seems similar to , which was fixed in / (which AFAIU should be included in ), but it still does not work.
Bisected to cc
the root cause is: if one place captured by more than 2 locations, the will be overrided by the last one in : In this case, is captured by at line 7 and at line 8, the captureinfo supercedes the previous .
Thank you for this!
Change:
let mut json_out = out_dir.join(self.testpaths.file.file_stem().unwrap()); json_out.set_extension("json"); let res = self.cmd2procres( <del> Command::new(&self.config.docck_python) </del> <ins> Command::new(&self.config.python) </ins> .arg(root.join("src/etc/check_missing_items.py")) .arg(&json_out), );

Discussion:
Compiletest currently has two different arguments telling it which python to use. Since , both are always the same. We should change it to just one argument to simplify things. Mentoring instructions: Change to be a single argument, then change to use the updated arguments. are you interested in tackling this one too? :) label +A-rustbuild +A-testsuite +E-easy +E-mentor Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
match args { Some(args) => panic!( <del> r#"assertion failed: `(left {} right)` left: `{:?}`, right: `{:?}`: {}"#, op, left, right, args </del> <ins> r#"assertion `left {op} right` failed: {args} left: {left:?} right: {right:?}"# </ins> ), None => panic!( <del> r#"assertion failed: `(left {} right)` left: `{:?}`, right: `{:?}`"#, op, left, right, </del> <ins> r#"assertion `left {op} right` failed left: {left:?} right: {right:?}"# </ins> ), } }

Discussion:
The custom message in macro is shown right after the . This is hard to read because the value strings could be very long. I think it is better to print the custom message (if available) on a separate line. The above (playground) prints this: Note that custom message and the location in source are still on the same line <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I will try it. claim
Note that the linked PR, , has a lot of review comments. I think rebasing that PR and addressing the comments would already be very close to landing this change.
(taking over due to inactivity) claim
:tada: Horray! It only took 548 days (1.5+ years) since I created on Feb 14th, 2022. Numerous commits. Tens of people. 4 PRs... 100s of files. All to change a few lines of output :) Special thanks to for all the support!
Change:
ret; } let new = fs::list_dir(buildpath); <del> let exec_suffix = os::exec_suffix(); </del> for ct: str in new { <del> if (exec_suffix != "" && str::ends_with(ct, exec_suffix)) || (exec_suffix == "" && !str::starts_with(ct, "./lib")) { run::run_program(ct, []); } </del> <ins> run::run_program(ct, []); </ins> } }

Discussion:
The documentation of and functions. In actual behaviour and , selects elements from when the mask bit is set and from otherwise. The Rust standard library documentation describes the other way around.
I believe I see the problem. Working on a PR now.
Change:
use errors::{DiagnosticBuilder, DiagnosticId}; use std::{hash, ptr}; use syntax::ast; <del> use syntax::source_map::{MultiSpan, ExpnFormat}; </del> <ins> use syntax::source_map::{MultiSpan, ExpnFormat, CompilerDesugaringKind}; </ins> use syntax::early_buffered_lints::BufferedEarlyLintId; use syntax::edition::Edition; use syntax::symbol::{Symbol, sym};

Discussion:
since
It is hitting the here: So I'm not quite sure why the error isn't being emitted yet.
It appears to be hitting this line of code which is cancelling the diagnostic:
this appears to be a stable-to-beta regression ()
triage: P-high. Assigning to self.
We need to change to not consider desugarings coming from loops as external. If that has regressions in our test suite, then we can add a new desugaring kind to differentiate between different parts of the for loop desugaring and target it further, but I do not expect that to be needed.
I've opened with a fix, based on comment.
Change:
<del> use crate::spec::{base, CodeModel, SanitizerSet, Target, TargetOptions}; </del> <ins> use std::borrow::Cow; use crate::spec::{base, CodeModel, SanitizerSet, SplitDebuginfo, Target, TargetOptions}; </ins> pub fn target() -> Target { Target {

Discussion:
On riscv64gc linux, split-debuginfo ="unpacked" caused error: A dwo section may not contain relocations. For rust 1.64, this error occurs. For rust <=1.64, cargo didn't pass flag to rustc. For rust 1.64, a segmentation fault happens in rustc. For rust < 1.64, it builds fine I think the behavior of rust < 1.64 is correct. The following steps: caused the following failure: No response Related:
Transferred to rust-lang/rust, since this looks to be a compiler issue.
says that LLVM doesn't support this combination of flags. It's unclear to me whether it's impossible or just not implemented yet, but in the meantime, cargo should probably stop passing -C split-debuginfo to proc-macros? there's some mention of in the upstream issue, I'm not sure how that's related.
The report above doesn't mention proc-macros. It seems to happen for normal binaries. The following seems to fail for me: If split-debuginfo isn't supported on this target, then rustc should report that it isn't supported (Cargo already tests for this). I believe that is defined by the field in the target definition.
I'm getting the same issue with when cross compiling for , it seems to be all values except that causes issues.
Change:
<ins> // revisions:rpass1 #![feature(const_generics)] struct FakeArray<T, const N: usize>(T); impl<T, const N: usize> FakeArray<T, { N }> { fn len(&self) -> usize { N } } fn main() { let fa = FakeArray::<u32, { 32 }>(1); assert_eq!(fa.len(), 32); } </ins>

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

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

A new project with the following code: Causes the following error:
Reduced: cc
Latest nightly shows a different compile error: error: internal compiler error: ty::TyKind::hashstable() - can't hash a TyVid _t.
Does not ICE anymore on playground - But does ICE in my local PC with latest nightly.
Can confirm it still ICE's with the latest nightly both in my little testing crate, and my larger project. The lack of ICE on the playground is very weird. Even copying my testing crate's code exactly doesn't make the ICE occur, even though both the playground and my computer run rustc .
Maybe a compiler flag? Not sure if playground uses . cc
The playground attempts to build each night, . You can always review exactly what version you are using in the channel dropdown: ! For what it’s worth, I don’t see the producing an error locally or in the playground.
Thank you very much, It is clear now that incremental compilation is the source of this behavior. To make a successful compilation with cargo, it is possible to use, for example, .
Change:
<ins> // revisions:rpass1 #![feature(const_generics)] struct FakeArray<T, const N: usize>(T); impl<T, const N: usize> FakeArray<T, { N }> { fn len(&self) -> usize { N } } fn main() { let fa = FakeArray::<u32, { 32 }>(1); assert_eq!(fa.len(), 32); } </ins>

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

Discussion:
stable is fine: but beta and nightly are no longer showing commit-hash and commit-date information: ` <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
it's weird because the info is still displayed correctly in the very first oneliner-summary, but if there was some tool that reads the data by looking at or we still should display the right thing.
This appears to have been introduced by . The issue is that the macro uses CFGVERDATE/CFGVERHASH which is only set when compiling rustc. One option is to try to share some code with . Another option is to go the other way and get rustc to share some code with .
Mentoring instructions: set in (Maybe we should try to unify those functions so they don't duplicate so much code and problems like this don't happen in the future?)
I think it should be possible to write a run-make test ensuring this works properly.
claim
Hi im starting my journey of contributing to Rust, i found this issue a good starter for myself, do you think you would be open to let me take this chance to get familiar with the code base?
Hey! Go for it!
Alternatively, you could check out . I THINK that might be more straightforward. But I'll let you decide(:
claim
I tried doing this change in Then i did a and tried running this command on the stage2 rustodc But it appears that the commit-hash and commit-date is still unknown. Im wondering if the issue is that is passed as true in This is my first time making changes and testing in this project, please feel free to correct me if im testing / building in the wrong way.
I'd suggest changing to use instead of so it's easier to tell when these variables are unset without having to build a full stage 2 compiler.
Retagging as stable/stable regression, this already shipped in 1.67 as far as I can tell.
Are you still (interested in) working on this issue? I'd like to claim it otherwise.
please go ahead and claim it!
claim
Change:
// Test syntax checks for `type` keyword. <del> struct S1 for type; //~ ERROR expected `{`, `(`, or `;` after struct name, found `for` </del> <ins> struct S1 for type; //~ ERROR expected `where`, `{`, `(`, or `;` after struct name, found `for` </ins> pub fn main() { }

Discussion:
(PR on top of )
seems to work. However, the syntax is awful, and requires a comma for disambiguation.
As of today nightly, that doesn't work anymore. It seems that where clauses don't work with tuple structs anymore. Any plans to support them in the future?
is this the desired syntax? I'm assuming it was chosen in order to do some kind of parsing disambiguation. I am willing to submit a small patch for this, just want clarification on the syntax.
hmm afaik they should work, and I would expect the syntax to be
I will track this one down and follow up with a PR.
You can get the current syntax to compile if the generic type bound uses the trait sugar: Nominating, since we won't be able to move the where clause to after the tuple after 1.0 without breakage.
Change:
} } <del> /// Extracts a field of a (variant of a) const. query const_field( key: ty::ParamEnvAnd<'tcx, (&'tcx ty::Const<'tcx>, mir::Field)> ) -> ConstValue<'tcx> { desc { "extract field of const" } } </del> /// Destructure a constant ADT or array into its variant index and its /// field values. query destructure_const(

Discussion:
Followup to I think we only have one use site of left: and it iterates over all fields anyway. So we can call instead and iterate over the resulting fields. There should be no more results for searching in the rust source after this, so some comments may need updating to mentioning instead of . These mentoring instructions are a bit vague, I do realize that, so if you encounter any hickup of any magnitude, don't hesitate to write here or contact me via discord/zulip. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
EDIT: Okay, it is a word. Still, to me "destruct" sounds better. But maybe that's just because I am used to theorem provers?
Change:
// Rewrite all `DICompileUnit` pointers to the `DICompileUnit` specified. See // the comment in `back/lto.rs` for why this exists. extern "C" void <del> LLVMRustLTOGetDICompileUnit(LLVMModuleRef Mod, </del> <ins> LLVMRustThinLTOGetDICompileUnit(LLVMModuleRef Mod, </ins> DICompileUnit **A, DICompileUnit **B) { Module *M = unwrap(Mod);

Discussion:
As of the 2021-09-23 nightly, rustc has stopped producing debug output for variables in a specific combination of circumstances: The variable is It is defined in a lib crate. The lib crate is included in a bin crate. The bin crate is built with . We noticed this after bumping past 09-23 to the 2021-10-27 nightly, when our debugger broke. The static is still being included in the ELF output (both allocated space, and represented correctly in the symtab), but is missing from DWARF. Bisecting indicates 2021-09-23 as the culprit (09-22 works). Here is a repro case that I've reduced that works on linux x86-64, at least, and probably other DWARF platforms. modify labels: +regression-from-stable-to-nightly -regression-untriaged
Bumping to regression-stable-to-beta, because 2021-09-23 is a 1.57 nightly. But would be good to confirm this reproduces on beta.
points at (). That being a rollup, looks the most relevant.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I think this may be a duplicate of . Please test on a current nightly, and when goes out it should have the backport via . It's still possible that introduced its own problem, but maybe it just exacerbated the LLVM issue.
It looks to me like the problem still reoccurs on the current nightly: <details<summaryFor completeness, here is a transcript showing the behavior that is expected, from nightly-2021-09-22</summary</details
This appears to still be reproducing as of ; we're stuck on because basically anything newer breaks our debugger.
So, after working out how to build a toolchain that includes our cross target and rust-lld and whatnot locally, I've tested today's mainline with a revert for PR , commit -- which had previously identified as the likely culprit. I can confirm that DWARF output for our statics on thumbv7em and kin is restored after that commit is reverted. Shall I prepare a PR?
Change:
self.ty_to_value_string(rcvr_ty.peel_refs()) }; if let SelfSource::MethodCall(_) = source { <del> let first_arg = if let Some(CandidateSource::Impl(impl_did)) = static_candidates.get(0) && let Some(assoc) = self.associated_value(*impl_did, item_name) && assoc.kind == ty::AssocKind::Fn { </del> <ins> let first_arg = static_candidates.get(0).and_then(|candidate_source| { let (assoc_did, self_ty) = match candidate_source { CandidateSource::Impl(impl_did) => { (*impl_did, self.tcx.type_of(*impl_did).instantiate_identity()) } CandidateSource::Trait(trait_did) => (*trait_did, rcvr_ty), }; let assoc = self.associated_value(assoc_did, item_name)?; if assoc.kind != ty::AssocKind::Fn { return None; } // for CandidateSource::Impl, `Self` will be instantiated to a concrete type // but for CandidateSource::Trait, `Self` is still `Self` </ins> let sig = self.tcx.fn_sig(assoc.def_id).instantiate_identity(); sig.inputs().skip_binder().get(0).and_then(|first| { <del> let impl_ty = self.tcx.type_of(*impl_did).instantiate_identity(); </del> // if the type of first arg is the same as the current impl type, we should take the first arg into assoc function <del> if first.peel_refs() == impl_ty { </del> <ins> let first_ty = first.peel_refs(); if first_ty == self_ty || first_ty == self.tcx.types.self_param { </ins> Some(first.ref_mutability().map_or("", |mutbl| mutbl.ref_prefix_str())) } else { None } }) <del> } else { None }; </del> <ins> }); </ins> let mut applicability = Applicability::MachineApplicable; let args = if let SelfSource::MethodCall(receiver) = source && let Some(args) = args

Discussion:
We had solved case in , could do the same for No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
Ok(new_blocks) => { debug!("inlined {}", callsite.callee); self.changed = true; <del> self.history.push(callsite.callee); </del> <ins> self.history.push(callsite.callee.def_id()); </ins> self.process_blocks(caller_body, new_blocks); self.history.pop(); }

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:
const VAL: u32 = dummy(0xFFFF); //~^ ERROR E0133 <del> //~| NOTE unsafe call requires unsafe function or block </del> <ins> //~| NOTE call to unsafe function </ins> fn main() { assert_eq!(VAL, 0xFFFF0000);

Discussion:
Label message always mention "unsafe call", even when nothing is actually called. It should duplicate the main message instead, or use some paraphrase of it. cc
How about this :
I've made a , please check the error messages again :)
Fix in , should be closed.