jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Check what happens when `func` is used to define a function, instead of `fn` // edition:2021 #![allow(dead_code)] func foo() {} //~^ ERROR expected one of `!` or `::`, found `foo` //~^^ HELP write `fn` instead of `func` to declare a function fn main() {} </ins>

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:
// (essentially libstd and all of its path dependencies) let std_src_dirs = [ "src/build_helper", <del> "src/backtrace", </del> <ins> "src/backtrace/src", </ins> "src/liballoc", "src/libcore", "src/libpanic_abort",

Discussion:
Not sure if this is due to the packaging, or if it is a rustup bug, but I cannot install the rust-src component for the latest nightly-2020-07-21. Fails on macOS and Linux with the same error. I'll try to dig in some tonight, but figured I'd file this to see if anyone has any ideas. If I had to take a wild guess, I would say it may be related to .
Rustup doesn't support symlink entry in tar file: There are two symlinks in backtrace:
cc
Once this is fixed we should look into checking that we're not creating these tarballs on the dist builders (rather than failing "late" when rustup fails to install)
Getting the same with (this might break ci of clippy/rustfmt/rls etc):
Posted a fix at .
Change:
} #[derive(Diagnostic)] <ins> #[diag(parse_missing_expression_in_for_loop)] pub(crate) struct MissingExpressionInForLoop { #[primary_span] #[suggestion( code = "/* expression */ ", applicability = "has-placeholders", style = "verbose" )] pub span: Span, } #[derive(Diagnostic)] </ins> #[diag(parse_missing_comma_after_match_arm)] pub(crate) struct MissingCommaAfterMatchArm { #[primary_span]

Discussion:
Spot the bug: Unfortunately, instead of pointing to the missing iterator, rust points to the 1: I'd love it to instead say 'missing iterator for loop': Other variants of this with less than ideal errors: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Well, it thinks the block is the iterator.
Yes, I understand, but a) is not an iterator, and b) since there's no body of the loop I was hoping the parser could recover somehow and understand that the block expression was intended to be the body.
Yes, I just wanted to make sure we were on the same page :)
I could have sworn there was an old ticket for this already but I can't find it
claim
Change:
&mut block.terminator.as_mut().unwrap(), &mut block.statements, ); <del> ctx.combine_duplicate_switch_targets(&mut block.terminator.as_mut().unwrap()); </del> <ins> combine_duplicate_switch_targets(block.terminator.as_mut().unwrap()); </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: no branch instructions emitted, makes an assumption that is , so should be inlined and optimized as a panic. Instead, this happened: there is a discriminant check still emitted. <!-- Provide the most recent version this worked on, for example: It most recently worked on: --It most recently worked on: nightly-2023-03-26 <!-- Provide the version you are using that has the regression. --See godbolt: Regression occurred in (cc searched nightlies: from nightly-2023-03-01 to nightly-2023-04-01 regressed nightly: nightly-2023-03-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: aarch64-unknown-linux-gnu Reproduce with: </details<details</summary(if you want to test on replace with ) </details<details</summary</details originally noticed the problem and opened , then suggested that this is a compiler issue, then that this is a regression, then bisected and opened this issue.
The end of this regression window is over 2 weeks from now. Why? Godbolt usually has pretty old nightlies. If I add : you can see we have duplicate switch targets, which means that either this commit is broken or godbolt doesn't have it:
godbolt seems to have ?
Because I knew that reproduces the regression, and wanted to cut some time bisecting. For reference I can reproduce the same issue with . <details<summary+nightly-2023-04-19 --emit=mir</summary</details
To be clear, separate from this issue I believe that this MIR: is a bug. I do not know what impact resolving that would have on this issue. But the helper that combines switch targets was (notionally) supposed to prevent this.
Yeah, I'm pretty sure that is the root cause.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
<del> error[E0277]: the trait bound `(): std::convert::From<{integer}>` is not satisfied --> $DIR/issue-32709.rs:4:5 </del> <ins> error[E0277]: `?` couldn't convert the error to `()` --> $DIR/issue-32709.rs:4:11 </ins> | LL |     Err(5)?; <del> |     ^^^^^^^ the trait `std::convert::From<{integer}>` is not implemented for `()` </del> <ins> |           ^ the trait `std::convert::From<{integer}>` is not implemented for `()` </ins> | = note: required by `std::convert::From::from`

Discussion:
Currently E277's message is confusing and seemingly ambiguous when it occurs on a try () expression (this may not be limited to E277, it's just the one I noticed). For example, in : The problem is that 's error type is while 's error type is . In this case the error isn't too confusing, but if the try is in a chained expression () and you're a noob it isn't clear why it wants implemented on . It doesn't necessarily even require a whole fix suggestion, all it would take is making the error only highlight the , as the issue is actually occuring when unwrapping the result. Thanks!
Change:
<del> //@ compile-flags: -Zvalidate-mir -Zinline-mir=yes //@ known-bug: #122909 use std::sync::{Arc, Context, Weak}; pub struct WeakOnce<T>(); impl<T> WeakOnce<T> { extern "rust-call" fn try_get(&self) -> Option<Arc<T>> {} pub fn get(&self) -> Arc<T> { self.try_get() .unwrap_or_else(|| panic!("Singleton {} not available", std::any::type_name::<T>())) } } </del>

Discussion:
<!-- [31mICE[0m: Rustc '-Zpolymorphize=on -Zinline-mir=yes -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'mentioneditems for DefId(0:15 ~ a[1172]::unsound) have not yet been set'', 'thread 'rustc' panicked at 'mentioneditems for DefId(0:15 ~ a[1172]::unsound) have not yet been set'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [optimizedmir] optimizing MIR for [unusedgenericparams] determining which generic parameters are unused by -- label +F-traitupcasting
Regression in nightly-2024-08-03 Regression in cc
Looks like another tainting issue to me -- we shouldn't be inlining MIR bodies that don't even pass type-checking... Cc

<!-- [31mICE[0m: Rustc '-Zpolymorphize=on -Zinline-mir=yes -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: Closure arguments are not passed as a tuple', 'error: internal compiler error: Closure arguments are not passed as a tuple' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [optimizedmir] optimizing MIR for [unusedgenericparams] determining which generic parameters are unused by [analysis] running analysis passes on this crate --
This one also seems to be cc
Change:
<ins> Available passes for running rustdoc: check_doc_test_visibility - run various visibility-related lints on doctests strip-hidden - strips all `#[doc(hidden)]` items from the output unindent-comments - removes excess indentation on comments in order for markdown to like it strip-private - strips all private items from a crate which cannot be seen externally, implies strip-priv-imports strip-priv-imports - strips all private import statements (`use`, `extern crate`) from a crate propagate-doc-cfg - propagates `#[doc(cfg(...))]` to child items collect-intra-doc-links - resolves intra-doc links check-code-block-syntax - validates syntax inside Rust code blocks collect-trait-impls - retrieves trait impls for items in the crate calculate-doc-coverage - counts the number of items with and without documentation check-invalid-html-tags - detects invalid HTML tags in doc comments check-bare-urls - detects URLs that are not hyperlinks Default passes for rustdoc: collect-trait-impls unindent-comments check_doc_test_visibility strip-hidden  (when not --document-hidden-items) strip-private  (when not --document-private-items) strip-priv-imports  (when --document-private-items) collect-intra-doc-links check-code-block-syntax check-invalid-html-tags propagate-doc-cfg check-bare-urls Passes run with `--show-coverage`: strip-hidden  (when not --document-hidden-items) strip-private  (when not --document-private-items) calculate-doc-coverage </ins>

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 command: I expected to see this happen: rustdoc shows a warning, the way it does for any other value you pass to : Instead, this happened: Rustdoc gives no warning and lists all passes. <!-- 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 --
Mentoring instructions: Move this check earlier to before is processed:
claim
Change:
<ins> // We used to ICE here while trying to synthesize auto trait impls. // issue: 114657 pub trait Foo { type FooType; } pub trait Bar<const A: usize>: Foo<FooType = <Self as Bar<A>>::BarType> { type BarType; } pub(crate) const B: usize = 5; pub trait Tec: Bar<B> {} pub struct Structure<C: Tec> { //~ ERROR the trait bound `C: Bar<5>` is not satisfied _field: C::BarType, //~ ERROR the trait bound `C: Bar<5>` is not satisfied } </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. --This is the least I've managed to reduce the code: <!-- 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. --: With nightly version the compiler asks me to change the as follows: and now the error no longer occurs. After running the command, I get the following: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<pOutput seems the same </p</details
Related if not duplicate of one of: , , . label -needs-triage T-rustdoc A-auto-traits A-synthetic-impls
I can't seem to reproduce the ICE with and
Me neither, seems to have been fixed. Potentially by err's “ PR” or by one of the PRs that made rustdoc execute more of rustc's stages. Fixed: ICE → errors (unsatisfied bounds).

<!-- 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
label A-synthetic-impls A-auto-traits T-compiler The bug originates in which lives in , so having both team labels is valid.
Bisection seems to point to nightly-2022-10-24, one of these:
Out of those, looks the most likely (from ).
I can no longer reproduce this. Fixed: ICE → errors. Probably fixed by one of those PRs that made rustdoc run more of rustc's passes.

Minimal example What I expected: works. What happens: (check & build work) No response No response
Thanks for the report! I have transferred this to rust-lang/rust as that is where rustdoc issues are tracked.
Seems to be a compiler bug. Adding the relevant tag.
Although the MCVE looks a bit esoteric, it actually comes from using  in an fairly straightforward way. I wouldn't be surprised if others have/will run into this.
Ran on this and found it regressed in The PR () states it's a revert of a previous commit. So maybe it was broken before the commit that needed reverting.
label A-auto-traits A-synthetic-impls
I can no longer reproduce this issue.
Change:
map.insert("toggle-all-docs".into(), 1); map.insert("all-types".into(), 1); map.insert("default-settings".into(), 1); <del> map.insert("rustdoc-vars".into(), 1); </del> map.insert("sidebar-vars".into(), 1); map.insert("copy-path".into(), 1); map.insert("TOC".into(), 1);

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. --The generated page HTML contains , which is not valid as per the (which only allows ). This has been the case since , which moved this div from the body to the header. I believe browsers will open the body if an invalid tag is encountered in the header (which you can see in inspect elements, where every item in between are inside of ), or something like that. This causes at least one bug: the attribute, which expands into a , is not displayed on Chrome and Chromium-based browsers. You can see this in the  crate on Chrome ! Firefox ! Generated HTML: vs : Manually moving the tag to the header correctly displays the favicon: ! !
label A-rustdoc-ui T-rustdoc
Thanks for the detailed report! Fixing it tomorrow.
Change:
/// Returns false if do not execute at all, otherwise returns its /// `status.success()`. pub(crate) fn check_run(&self, cmd: &mut BootstrapCommand) -> bool { <del> if self.dry_run() { </del> <ins> if self.dry_run() && !cmd.run_always { </ins> return true; } self.verbose(|| println!("running: {cmd:?}"));

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:
<del> warning-crlf.rs eol=crlf </del> <ins> warning-crlf.rs -text </ins>

Discussion:
Right now using to manage the rust-lang/rust repo locally causes to fail: This is a result of which is responsible for adding the character to the failing test. While I would love to get that support to jj upstream I'm assuming it is non-trivial and I'd like a better solution in the short term so I can continue to use while contributing to the compiler. suggested I use in the meantime which I'm fine with but I'd like a way to set this in my or some equivalent mechanism doesn't require manually adding this set of arguments to every invocation of I make.
note this is essentially the same as i actually would like an even more general solution, where the flags and configs are completely interchangable and you can specify either in either place, but a solution just for seems ok too. label T-bootstrap A-contributor-roadblock
So it turns out that won't work as a short term fix even because does not work with tidy atm. For now I'm going with but I expect this to break frequently and be a source of annoyance so I'll be looking towards fixing this soon if it does in fact end up being a problem.
re crlf, as a source control expert I'd recommend never using any kind of autoconversion -- it is a bit of a nightmare to work with in too many cases. Rather, I'd consider checking in the file with CRLFs, and disabling autoconversion so files are always checked out as-is. (Another option is to effectively treat the file as binary content, e.g. use some other means of encoding the file, such as base64 or putting it in a tarball. But I don't know how practical that is)
Change:
<ins> // Copyright 2016 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. trait Q<T:?Sized> {} trait Foo where u32: Q<Self> { fn foo(&self); } impl Q<()> for u32 {} impl Foo for () { fn foo(&self) { println!("foo!"); } } fn main() { let _f: Box<Foo> = //~ ERROR `Foo` cannot be made into an object Box::new(()); //~ ERROR `Foo` cannot be made into an object } </ins>

Discussion:
the following generates a compiler error on all current versions: RUST_BACKTRACE hangs for me, but emits: error: internal compiler error: Unexpected type in full type resolver: FreshTy(0) This is greatly cut down from a real world example, and a blocking issue for me
This is a regression of the release (over ) of rust.
triage: P-medium Pretty old regression, barely qualifies. =) However, says he has a fix.
Oh sorry, disregary my comment above, the issue is reproducible on 1.3.0 as well as on stable 1.0.0. Its not a regression, at least not one from a stable rust release.
Change:
let path = match def.full_def() { def::DefStruct(def_id) => def_to_path(tcx, def_id), def::DefVariant(_, variant_did, _) => def_to_path(tcx, variant_did), <ins> def::DefFn(..) => return P(hir::Pat { id: expr.id, node: hir::PatLit(P(expr.clone())), span: span, }), </ins> _ => unreachable!() }; let pats = args.iter().map(|expr| const_expr_to_pat(tcx, &**expr, span)).collect();

Discussion:
at the current version of error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'internal error: entered unreachable code', playpen: application terminated with error code 101
The reason this is happening is because the code thinks is an enum variant or a tuple struct. The code around this is somewhat redundant and would probably better be solved by making enum variants const evaluable and adding a function that translates s to

This code wrongly states "expected constant integer for repeat count, but non-constant path in constant expression" This one works
accidentally fixed in