jiebi/CodeConvo huggingface dataset:
Change:
appl, ); } <ins> if ["def", "fun", "func", "function"].contains(&symbol.as_str()) { err.span_suggestion_short( self.prev_token.span, &format!("write `fn` instead of `{symbol}` to declare a function"), "fn", appl, ); } </ins> } // Add suggestion for a missing closing angle bracket if '>' is included in expected_tokens

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: <!-- Please provide a link to --The current output is: Ideally the error message should suggest replacing or with . <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
New to rustc community and wants to contribute code. there any options to debug rustc which line of which file the error abort happens? can I dump the hierarchy tree for debugging use? C++ we usually use env for compiler debugging. How do rustc often use? Very newbie questions, thank you in advance.
label +E-easy +E-mentor Welcome to Rust! This might be some help -- This issue is very similar to , so take a peek at the diff there. IMO the following tokens are enough to check against function (Julia/JavaScript/etc) func (Go) fun (Kotlin) def (Python) Have fun! <3
Instructions -- Add a check if prevtoken is either ///etc Emit a message, something along the lines of "use instead of <prevtokento make a function" using , there are a few usages of this in the same file so those might be good examples. Add tests for this in -- Ideally each suggestion would have a test. Should be helpful to take as a reference
We can include if necessary.
Hi guys, another rust newbie looking for something easy to get started here. are you still on this or could go with my attempt here?

ypprog does seem to be active and it hasn't been that long, if you'd like you can pick another issue. =) Try going through the E-Easy and/or E-Mentor category for easy issues. However, to clarify, if an issue which is claimed doesn't seem to have any work done for a long period of time (A month or so is a good amount of time) -- Feel free to ping the assignee to confirm and handle it accordingly.
With these changes, I also think it is important to implement improved error messages for when a user puts the return type at the start of the function instead of the end. Given this code: The error output is:
I feel like adding might also be helpful for C++ developers :)
Is this still being worked on?
release-assignment
claim
Change:
<ins> // only-x86_64 #[cfg(target_arch = "x86")] use std::arch::x86::*; #[cfg(target_arch = "x86_64")] use std::arch::x86_64::*; unsafe fn pclmul(a: __m128i, b: __m128i, imm8: i32) -> __m128i { _mm_clmulepi64_si128(a, b, imm8) //~ ERROR argument 3 is required to be a constant } fn main() {} </ins>

Discussion:
Expected the following code to compile But getting Repro:
Also happens on beta, not on stable
Stable says:
For reference, the function signature as defined is exactly the same.
The actual ICE occurs first in nightly-2019-03-03 (...). But interesting enough, stable (as jonas pointed out) procuces an error, saying, that the third argument must be a constant. Since nightly-2019-02-16 (...) this does not emit an error anymore, but also does not ICE.
I guess for the "does not emit an error anymore" can say something about it. should be responsible for it.
triage: P-high
Note that because of the on the definition, you can't wrap it (without matching on and having 256 separate calls). I don't think this is intentional, but I'm not sure why it would happen, maybe arguments are treated incorrectly in the qualifier. cc
So I agree that this code can't compile, that's the expected behavior; if you want to wrap it, you have to use a macro - Rust functions aren't able to abstract over this type of hardware operations yet. The ICE is a regression over the error message that was being produced before. We should definitely add an ui test for that.
triage, assigning to self to fix the stable-to-beta regression.
The behavior here varies with edition as well as channel. edition 2018 ------------------ ------------------------ stable expected error beta unexpected compile-pass nightly-2019-04-05 ICE I think the most immediate thing to address is the unexpected compile-pass that has leaked into beta.
The easiest thing might be to revert
I have an actual fix in (also easier to backport than a revert)
Okay then I'm reassigning to
Change:
asserts: bool, ) -> bool { let if_unchanged = || { <del> // Git is needed to track modifications here, but tarball source is not available. // If not modified here or built through tarball source, we maintain consistency // with '"if available"'. if !self.rust_info.is_from_tarball() && self .last_modified_commit(&["src/llvm-project"], "download-ci-llvm", true) .is_none() { // there are some untracked changes in the given paths. false } else { llvm::is_ci_llvm_available(self, asserts) </del> <ins> if self.rust_info.is_from_tarball() { // Git is needed for running "if-unchanged" logic. println!( "WARNING: 'if-unchanged' has no effect on tarball sources; ignoring `download-ci-llvm`." ); return false; </ins> } <ins> self.update_submodule("src/llvm-project"); // Check for untracked changes in `src/llvm-project`. let has_changes = self .last_modified_commit(&["src/llvm-project"], "download-ci-llvm", true) .is_none(); // Return false if there are untracked changes, otherwise check if CI LLVM is available. if has_changes { false } else { llvm::is_ci_llvm_available(self, asserts) } </ins> }; match download_ci_llvm {

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: in is not specified explicitly, the default value is used. I expected to see this happen: LLVM is downloaded from CI, when LLVM version is bumped the new LLVM is downloaded from CI as well. Instead, this happened: LLVM starts building from source code after an LLVM update, instead of being downloaded, unless I remove the build directory and do a fresh build, then it starts downloading from CI again. <!-- 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. --:
Or maybe it's a stage0 toolchain update that triggers this issue, not LLVM update (I observed this today). But I've seen this issue several times in the past as well. cc
The section in is completely empty, nothing is overridden.
Update: LLVM is built from source only on the first build attempt, after that it is correctly downloaded from CI.
This is still an issue that I observe regularly.
There were some issues with the change detection logic for LLVM and I think should fix it. Let's see if it still happens with the next LLVM update.
Change:
<ins> // run-rustfix #![allow(dead_code)] // https://github.com/rust-lang/rust/issues/112007 fn bug_report<W: std::fmt::Write>(w: &mut W) -> std::fmt::Result { if true { writeln!(w, "`;?` here ->")?; } else { return writeln!(w, "but not here"); //~^ ERROR mismatched types }; Ok(()) } macro_rules! baz { ($w: expr) => { bar!($w) } } macro_rules! bar { ($w: expr) => { writeln!($w, "but not here") //~^ ERROR mismatched types } } fn foo<W: std::fmt::Write>(w: &mut W) -> std::fmt::Result { if true { writeln!(w, "`;?` here ->")?; } else { return baz!(w); }; Ok(()) } fn main() {} </ins>

Discussion:
The suggestion converts the code to: which is invalid. It should suggest: The suggestion works correctly for non-macro string values. This suggestion was introduced in . No response
It cannot be reproduced on .
I'm able to reproduce it locally. It seems to be suggesting a change in : (note the path) I assume that this is due to macro expansion. It might not be working on the playground because the playground doesn't have the component installed but that's a total guess.
The presence of only affects the human-readable rendering. The important part to me is the JSON output which has even without rust-src. Ideally it would be something closer to what it looks like with :
It seems to affect all macro expansions ():
Is the solution to just disable this suggestion for macro-expanded code? As an aside, perhaps the playground should get , especially because of its prevalence in sharing code which might need the additional context.
I think it's possible to achieve the desired output found in the description, although I'm not sure how exactly. Typically, you would use on the span to peel away the layers of macro invocations, though for that you would need to provide a parent to mark the end of the chain. doesn't need such a stopper but here its use would be incorrect if the macro call itself (e.g. ) was inside of a macro expansion. Since we don't have a parent (afaiaa), earlier I briefly tried to create a parent for via I think but that didn't work. Maybe could work, not sure. This approach is a catch-22 I believe.
Yeah, would that be the desired solution though? Can this be generalized to all the other type mismatch suggestions?
That's a good question. It was mostly an experiment to see if this specific issue can be solved with .
Change:
self.sess.gated_spans.gate(sym::unnamed_fields, lo); } else { let err = if self.check_fn_front_matter(false) { <del> let _ = self.parse_fn(&mut Vec::new(), |_| true, lo); </del> <ins> // We use `parse_fn` to get a span for the function if let Err(mut db) = self.parse_fn(&mut Vec::new(), |_| true, lo) { db.delay_as_bug(); } </ins> let mut err = self.struct_span_err( lo.to(self.prev_token.span), &format!("functions are not allowed in {} definitions", adt_ty),

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
This regressed in , which is a rollup. Luckily is the only real candidate though. The panic that gets called is this one: From a quick scan of a result gets dropped here : cc searched nightlies: from nightly-2021-05-07 to nightly-2021-05-29 regressed nightly: nightly-2021-05-09 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </details
Mhh, I don't even remember why I this call to in the first place, maybe to consume the fn body and get fewer/cleaner errors? Should have a comment... Anyway fixing this should be easy, we can (or ) the error, or remove the call to .
Change:
<del> Subproject commit a04279dd5736be294843af15ac07ca499c02acef </del> <ins> Subproject commit ec995b75d71c5f3b9a82fe084259477eb22f74da </ins>

Discussion:
I'm really sorry if this isn't a compiler bug, but it smells like one. I've managed to bag it into a few lines of code. Change or reorder anything and the test will pass. If you run this repo it will pass: If you add in it will fail. ( You will need to ) It seems to correctly figure out that the condion is false but then take the true branch of the if anyway. There's no unsafe in the code so there should be no UB.... Why for instance does have to be there for the bug to manifest itself? I am clueless... This is with the latest nightly ( rustc 1.54.0-nightly ( 2021-05-21) ), but have confirmed it fails on beta too. I would love to know what is going on - it seems very wierd behaviour.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Smells like an LLVM miscompilation issue? Since it is target-specific, a MIR issue seems unlikely. Cc
I'm afraid the ping didn't work ~ ping cc:
Error: This team () cannot be pinged via this command; it may need to be to on the master branch. Please let know if you're having trouble with this bot.
Error: This team () cannot be pinged via this command; it may need to be to on the master branch. Please let know if you're having trouble with this bot.
With Note that reads a local that has not been initialized.
Upstream issue:
Change:
/// Builds the `rust-docs-json` installer component. fn run(self, builder: &Builder<'_>) -> Option<GeneratedTarball> { let host = self.host; <del> builder.ensure(crate::doc::JsonStd { stage: builder.top_stage, target: host }); </del> <ins> builder.ensure(crate::doc::Std { stage: builder.top_stage, target: host, format: DocumentationFormat::JSON, }); </ins> let dest = "share/doc/rust/json";

Discussion:
running only builds the html doc, but builds the json doc. I expected the json flag to act as the documentation says (): using the master branch of this repo commit running with a library profile.
I can't reproduce this. The files show up for me in .
Seems to reproduce, I could totally have overlooked a step tho
oh no it's even simpler than that lol it's calling the wrong function that should be JsonStd, not Std
Should I make the PR or are you gonna do it ?
If you could make a PR that would be great :)
Made the PR but since just changing the ensure wasn't enough there's a thing I'm unsure about (tested it, worked, but could be cleaner)
Change:
``` Or, if you tried to use a module from an external crate, you may have missed <del> the `extern crate` declaration: </del> <ins> the `extern crate` declaration (which is usually placed in the crate root): </ins> ```ignore extern crate homura; // Required to use the `homura` crate

Discussion:
Exemple code: Error is: The compiler should detect that "self" is missing. Note this is an error I do all the time as a beginner.
Even without doing an analysis of what could have likely been intended this error message could mention that paths in are absolute by default, unless they start with or .
Ran into this a few days ago, would love to the messaging here improved :+1:
The linked PR adds the information to the long diagnostics, at least. Note that if you just have an then the error message is markedly different: I wonder if some consolidation would be in order.
Fixed in .
Change:
} else if let UseSpans::FnSelfUse { kind: CallKind::Normal { .. }, .. } = move_spans { // We already suggest cloning for these cases in `explain_captures`. <ins> } else if let UseSpans::ClosureUse { closure_kind: ClosureKind::Coroutine(CoroutineKind::Desugared(_, CoroutineSource::Block)), args_span: _, capture_kind_span: _, path_span, } = move_spans { self.suggest_cloning(err, ty, expr, path_span); </ins> } else if self.suggest_hoisting_call_outside_loop(err, expr) { // The place where the the type moves would be misleading to suggest clone. // #121466

Discussion:
I expect that the invocation to be for the value that is moved, but for some reason it is doing it for the entire closure. No response No response
label +E-needs-mcve
MCVE or
Change:
kw::Extern, kw::Impl, kw::Unsafe, <ins> kw::Const, </ins> kw::Static, kw::Union, kw::Macro,

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output on stable 1.63.0: The current output on Beta version 1.64.0-beta.6 (2022-09-09 ): The current output on Nightly version 1.65.0-nightly (2022-09-09 ): Since ( cc ) is somewhat recent the help diagnostics improvement currently is only on beta. However, the latest nightly has regressions regarding the suggestion as shown above. Hence, the output should suggest changing with as that is the desired output. Note: base issue for improved diagnostics ( -): Note: since this is technically a regression from beta to nightly, what should be the appropriate label to add? The one below this? label +regression-untriaged <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Can you please add the Rustc versions?
[Note that I don't think this should have happened at all, I wrote tests for the changed diagnostic suggestions]
I have retested the above code snippet against the current stable, beta and nightly version (I have the version numbers above) of the compiler in the official rust playground and the regression still persist. Not sure if this only occurs on the rust playground although I highly doubt it. Maybe you could look into this as the implementation of that diagnostics improvement is written by you. If you have any evidence that this regression issue is misinformed do let me know and I will happily close the issue. Thanks a lot.

Not sure if this is the cause but maybe the test you wrote in is slightly different to the above code snippet as the test uses the wrong keyword in the top-level. However, the above code snippet uses the incorrect keyword inside of a user-defined module. Hence, this may lead to a PR that potentially causes a regression in the recovery of -to not trip off a CI fail. Therefore, undetected. That being said, all those are just my guess and it may be wrong. label +E-needs-bisection
This may related to my PR:
claim
label -E-needs-bisection
Change:
require, residual, result, <ins> resume, </ins> return_position_impl_trait_in_trait, return_type_notation, rhs,

Discussion:
In , I a combinator that always returns . However, the corresponding test in crashes with a segfault, instead of hanging indefinitely (the expected behavior for this incomplete implementation). According to GDB, the test function is miscompiled quite badly, and just unconditionally dereferences a NULL pointer when run: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Is this like... the futures version of
I'll minimize this a bit claim
Uhh this is as much as I could minimize it -- not sure if it's segfaulting because I minimized it poorly or because it actually repro's this issue, but it's a start!! :laughing: <details</details
Thanks I was able to use your test case to look into it a bit further. The issue looks related to the Future trait, I wasn't able to reproduce it using other traits. In the example below I changed the trait definition to this: And the call to fails to compile with this LLVM error: Compile in debug mode to see the error, release mode doesn't complain and outputs code that segfaults. <details</details
In , the call to is incorrectly resolved to , i.e., .
Thanks I can look into why we're resolving this method to the wrong instance...
Ah. This isn't a user-facing bug, but a bug in that expects the trait to have one method. :facepalm: So it turns out that this really isn't that high-prio of a bug. It still needs fixing, and that method could use some major robustness checks, at least when debug assertions are enabled. I'll take a stab at it. claim
I'm going to remove the unsoundness tag and I think this probably doesn't need to be prioritized (or at least doesn't need to be anything higher than like... P-high) because this really has to do with an incongruency between and the compiler's assumption about the contents of the trait. That being said, this bug still sucks and I'm sorry that had to deal with it, but nothing like this is possible to trigger without and a trait definition for that diverges from the one in libstd currently. (that being said, I will still fix this bug and make it harder to trigger in the future)
Change:
pub(super) fn recover_parens_around_for_head( &mut self, pat: P<Pat>, <del> expr: &Expr, </del> begin_paren: Option<Span>, ) -> P<Pat> { match (&self.token.kind, begin_paren) { (token::CloseDelim(token::Paren), Some(begin_par_sp)) => { self.bump(); <del> let pat_str = self // Remove the `(` from the span of the pattern: .span_to_snippet(pat.span.trim_start(begin_par_sp).unwrap()) .unwrap_or_else(|_| pprust::pat_to_string(&pat)); self.struct_span_err(self.prev_token.span, "unexpected closing `)`") .span_label(begin_par_sp, "opening `(`") .span_suggestion( begin_par_sp.to(self.prev_token.span), "remove parenthesis in `for` loop", format!("{} in {}", pat_str, pprust::expr_to_string(&expr)), // With e.g. `for (x) in y)` this would replace `(x) in y)` // with `x) in y)` which is syntactically invalid. // However, this is prevented before we get here. Applicability::MachineApplicable, ) .emit(); </del> <ins> self.struct_span_err( MultiSpan::from_spans(vec![begin_par_sp, self.prev_token.span]), "unexpected parenthesis surrounding `for` loop head", ) .multipart_suggestion( "remove parenthesis in `for` loop", vec![(begin_par_sp, String::new()), (self.prev_token.span, String::new())], // With e.g. `for (x) in y)` this would replace `(x) in y)` // with `x) in y)` which is syntactically invalid. // However, this is prevented before we get here. Applicability::MachineApplicable, ) .emit(); </ins> // Unwrap `(pat)` into `pat` to avoid the `unused_parens` lint. pat.and_then(|pat| match pat.kind {

Discussion:
Roughly according to cc
Some notes: I think this is not worth fixing as it would require hacks deep in the general sequence parser. We should try to still have suggestions; notes that there are special purpose methods for doing that. "Unnecessary" is semantically misleading here as this is a hard error, not a lint.
Change:
// field; see #8506. C_null(type_of::sizing_type_of(ccx, ty)) }).collect::<Vec<ValueRef>>(); <del> C_struct(ccx, &build_const_struct(ccx, &nonnull, &vals[..]), false) </del> <ins> C_struct(ccx, &build_const_struct(ccx, &nonnull, &vals[..]), false) </ins> } } _ => bug!("trans_const: cannot handle type {} repreented as {:#?}", t, l)

Discussion:
This code () gives me a segfault on the current beta: I've reduced it as much as I can, even removing the constructor on the enum causes it to work. I expect the output to be (which it is on stable), but instead I get
Appears to be broken on nightly as well - I get a stack overflow on x86_64 darwin.
FWIW, I don't get a segfault on beta or nightly with the playpen, I just get this output for both:
The stackoverflow on x86_64 darwin goes away for me on any .
This strongly reminds me of and .