jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: expected one of `!` or `::`, found `foo` --> $DIR/fn-defined-using-function.rs:6:10 | LL | function foo() {} | -------- ^^^ expected one of `!` or `::` | | | help: write `fn` instead of `function` to declare a function error: aborting due to previous error </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:
<ins> // Issue #118164: recovery path leaving unemitted error behind fn bar() -> String { #[cfg(feature = )] [1, 2, 3].iter().map().collect::<String>() //~ ERROR expected `;`, found `#` #[attr] //~ ERROR expected statement after outer attribute } fn main() { let _ = bar(); } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: the following error was constructed but not emitted', 'error: internal compiler error: the following error was constructed but not emitted' File: --snippet: Version information but still crashes with ` 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: --
Reduced further: searched nightlies: from nightly-2023-11-17 to nightly-2023-12-02 regressed nightly: nightly-2023-11-21 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.7</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </detailsLooks like
This might be a duplicate of , now that I've taken another look at it
When I checked, was already fixed but this one wasn't
You're right-- doesn't reproduce with the latest nightly, but this one does, which I find strange since I thought they have the same root cause, which should address. (Hence also why I closed --it almost exactly duplicated the work in .)
Can be further reduced to

<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: the following error was constructed but not emitted', 'error: internal compiler error: the following error was constructed but not emitted' File: --snippet: 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: --
Regression in nightly-2023-11-21 ping
I found that the code snippet does not cause ICE anymore. Meta: Output:
Change:
<ins> // Issue #118164: recovery path leaving unemitted error behind fn bar() -> String { #[cfg(feature = )] [1, 2, 3].iter().map().collect::<String>() //~ ERROR expected `;`, found `#` #[attr] //~ ERROR expected statement after outer attribute } fn main() { let _ = bar(); } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '--crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: not a tail expression', 'error: internal compiler error: not a tail expression' 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: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It seems the pops up since cc The code starts ICEing in general since cc
claim
Change:
// Initialize the llvm submodule if not initialized already. // If submodules are disabled, this does nothing. <del> builder.update_submodule("src/llvm-project"); </del> <ins> builder.config.update_submodule("src/llvm-project"); </ins> let root = "src/llvm-project/llvm"; let out_dir = builder.llvm_out(target);

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> Subproject commit 2d1947ff34d50ca46dfe242ad75531a4c429bb52 </del> <ins> Subproject commit b6d4a4940bab85cc91eec70cc2e3096dd48da62d </ins>

Discussion:
TOC entries for impls contain special characters like etc and the links are not sanitized correctly per pandoc's rules.
Change:
_ => { let name = pprust::path_to_string(path); span_err!(tcx.sess, pat.span, E0164, <del> "`{}` does not name a variant or a tuple struct", name); </del> <ins> "`{}` does not name a non-struct variant or a tuple struct", name); </ins> fcx.write_error(pat.id); if let Some(ref subpats) = *subpats {

Discussion:
struct variants have been unfeature gated, but there are corner cases that we did not intend. Here is (playpen compatible) code that demonstrates this: link:
Nomating for P-backcompat-lang, 1.0
Change:
// Env updates. (fn(&ENV e, @ast.crate c) -> ENV) update_env_for_crate, (fn(&ENV e, @item i) -> ENV) update_env_for_item, <ins> (fn(&ENV e, @view_item i) -> ENV) update_env_for_view_item, </ins> (fn(&ENV e, &block b) -> ENV) update_env_for_block, (fn(&ENV e, @stmt s) -> ENV) update_env_for_stmt, (fn(&ENV e, @decl i) -> ENV) update_env_for_decl,

Discussion:
I was trying to build the stdlibs for the target like this: However, the build fails with the following error: Here is the full build log: I'm using Xubuntu 15.10. At the time of building, the Rust master was at .
Unfortunately is a which means that we don't guarantee that it builds in-tree right now. Patches are certainly welcome to fix this, however! We tend to not keep issues tracking build support for all Tier 3 platforms, however, so I'm going to close this. If you're interested in promoting this to at least tier 2 you could also help modify out to be able to support this target!
Change:
let mut any_resolved = false; let mut need_assoc = false; for ns in [TypeNS, ValueNS, MacroNS] { <del> if self.resolve_and_cache_rustdoc_path(&path_str, ns) { any_resolved = true; </del> <ins> if let Some(res) = self.resolve_and_cache_rustdoc_path(&path_str, ns) { // Rustdoc ignores tool attribute resolutions and attempts // to resolve their prefixes for diagnostics. any_resolved = !matches!(res, Res::NonMacroAttr(NonMacroAttrKind::Tool)); </ins> } else if ns != MacroNS { need_assoc = true; }

Discussion:
Using cargo 1.71.0-nightly ( 2023-05-02) or cargo 1.69.0 ( 2023-04-12), I get a crash when trying to generate documentation from this excerpt of the Matrix Rust SDK: <details<summary<strongBacktrace</strong</summary</details
Change:
fn f2<'a>(x: u8, y: Vec<&'a ...>) {} //~^ ERROR C-variadic type `...` may not be nested inside another type <ins> // Regression test for issue #125847. fn f3() where for<> ...: {} //~^ ERROR C-variadic type `...` may not be nested inside another type </ins> fn main() { let _recovery_witness: () = 0; //~^ ERROR: mismatched types

Discussion:
<!-- [31mICE[0m: Rustc '-Zunstable-options --edition=2024 -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error: should have been handled elsewhere', 'error: internal compiler error: should have been handled elsewhere' 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: --
also repros with or with 2015 if you remove the :)
Regression in nightly-2020-12-20 fetching (via remote github) commits from max(, 2020-12-17) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 9 commit[0] 2020-12-18: Auto merge of - ehuss:update-cargo, r=Mark-Simulacrum commit[1] 2020-12-18: Auto merge of - GuillaumeGomez:str-to-symbol, r=jyn514 commit[2] 2020-12-19: Auto merge of - mibac138:fn-fat-arrow-return, r=davidtwco commit[3] 2020-12-19: Auto merge of - davidtwco:issue--const-param-attrs, r=lcnr commit[4] 2020-12-19: Auto merge of - JohnTitor:rollup-a31s996, r=JohnTitor commit[5] 2020-12-19: Auto merge of - jackh726:binder-refactor-part-2, r=lcnr commit[6] 2020-12-19: Auto merge of - CDirkx:ipaddr-const, r=oli-obk commit[7] 2020-12-19: Auto merge of - matthewjasper:revert-eval-order, r=nikomatsakis commit[8] 2020-12-19: Auto merge of - Nadrieril:usefulness-merging, r=varkor
This is also kinda bad because rustc does not tell you what you did wrong (theres no error shown) mvce:
very likely
Change:
<ins> // Copyright 2014 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. // Test calling methods on an impl for a bare trait. This test checks that the // trait impl is only applied to a trait object, not concrete types which implement // the trait. trait T {} impl<'a> T+'a { fn foo(&self) {} } impl T for int {} fn main() { let x = &42i; x.foo(); //~ERROR: type `&int` does not implement any method in scope named `foo` } </ins>

Discussion:
This code: generates this error: I couldn't find any existing issue on this, but this is expected to work, right?
cc
Was this in an RFC?
DST was pre-RFC (the design anyway), so no, it was not.
It as a good question whether this is supposed to work or not. Since traits are types now, just unsized, I would say "yes". But since an impl for a trait is no different to just providing default methods, perhaps we want to avoid that overlap. Shouldn't be hard to fix if we all agree on "yes", but cc to check he agrees.
As I understand it, an for a trait would be quite different than providing default methods: Even when a trait object is formed, there's no dynamic dispatch (vtable entries) for these methods. The methods cannot be overridden in an . The methods may also exist on the trait, in which case (according to our dispatch rules) the inherent versions would take precedence. I think the closer correspondence is to creating an extension trait with a blanket -- and given that inherent s are in some sense supposed to be equivalent to "anonymous", always-in-scope extension traits, I think that makes sense. My guess is that this was an intended, but implicit part of the DST proposal, but can speak more directly to that.
These subtle differences make me want it less. But the blanket impl-like use case seems legitimate. I agree with the intended but implicit assessment - I vaguely remember this coming up as a use case at some point
I've always assumed this would work but I'm curious was there a specific point in the libraries that required it?
IIRC this came out of playing around with the method definitions, which are currently all provided by extension traits. Not a huge deal if we can't do this for 1.0.
I started looking at this, but the hard bits seem to be some adjustment to method selection, so I'll wait on landing before doing this
I think there is some serious utility in providing this, especially for things like Any. I will try to dig up some other use-cases. Note that since is currently marked adding this later would mean deprecations etc.
Change:
<ins> // regression test for #109298 // edition: 2021 pub fn subslice_array(x: [u8; 3]) { let f = || { let [_x @ ..] = x; let [ref y, ref mut z @ ..] = x; //~ ERROR cannot borrow `x[..]` as mutable }; f(); //~ ERROR cannot borrow `f` as mutable } fn main() {} </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. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Probably fixed by (
searched nightlies: from nightly-2022-12-30 to nightly-2023-03-18 regressed nightly: nightly-2023-01-01 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegression in same as ..?
You should update your cargo-bisect-rustc version to make it bisect the contents of rollups as well^^
I already have the git version installed :o
Note that we don't have the artifacts for all rollups. I think it requires a perf bisection to be run on the pr or something?
Regression in nightly-2021-09-01 `
Ah, the rollup predates unrolled builds.
I think this is a different issue, it's not fixed by that PR anyway. I'll try and investigate anyway claim The ICE occurs while trying to report this error Changing to fails earlier:
Actually this can be reduced further -
Change:
}, Some(c) => c, }, <del> TokenKind::RawIdent | TokenKind::UnknownPrefix | TokenKind::InvalidIdent => { Class::Ident(self.new_span(before, text)) } </del> <ins> TokenKind::RawIdent | TokenKind::UnknownPrefix | TokenKind::InvalidPrefix | TokenKind::InvalidIdent => Class::Ident(self.new_span(before, text)), </ins> TokenKind::Lifetime { .. } => Class::Lifetime, TokenKind::Eof => panic!("Eof in advance"), };

Discussion:
In the 2015 and 2018 editions, the following compiles (with warnings): ` [playground] The is taken as an identifier, although emoji aren't generally permitted in identifiers in any edition. I tested with 1.77.1. I think the underlying problem is that and in distinguish "identifiers" containing emoji (as rather than ), but don't have a way to make that distinction for . [playground]:
Regression from 1.57 to 1.58 (stable to stable). Very likely in , cc Regression from error to pass. Previous error: .
WG-prioritization assigning priority (). label -I-prioritize +P-low
thank you for the detailed report. will fix this.
Change:
lint_improper_ctypes_pat_help = consider using the base type instead lint_improper_ctypes_pat_reason = pattern types have no C equivalent <del> lint_improper_ctypes_recursion_limit_reached = type is infinitely recursive </del> lint_improper_ctypes_slice_help = consider using a raw pointer instead lint_improper_ctypes_slice_reason = slices have no C equivalent

Discussion:
The windows-rs crate is getting a whole bunch of spurious FFI-safe warnings: See: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc which introduced the recursion limit.
Repro:
Anyways I'll put up a revert PR claim
Change:
"crypto-hash", "curl", "curl-sys", <del> "env_logger 0.7.0", </del> <ins> "env_logger 0.7.1", </ins> "failure", "filetime", "flate2",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
triage: has PR (in ). Marking P-medium and removing nomination.
Change:
<ins> type Result<T, E = Error> = ::std::result::Result<T, E>; struct Error; trait ForEach { type Input; fn for_each<F, U>(self, f: F) where F: FnOnce(Self::Input) -> U; } impl<T> ForEach for A<T> { type Input = T; fn for_each<F, U>(self, f: F) where F: FnOnce(Self::Input) -> U, { todo!() } } struct A<T>(T); fn main() { let a = A(Result::Ok(Result::Ok(()))); //~ ERROR type annotations needed a.for_each(|a: Result<_>| { let f = || match a { Ok(Ok(a)) => {} Ok(Err(a)) => {} Err(a) => {} }; }); } </ins>

Discussion:
<details</summary</details<!-- 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. --:
I will try to reduce this to an MCVE.
Changing to appears to avoid the ICE, so that may be a useful place to focus.
Minimized it down to 60 lines without any dependencies. Maybe it can be minimized further but it's getting really hard. I've also left a few comments to say what's going on. <details<summary"Minimized" </summary</details
This appears to have regressed in Rust 1.64
This continues to ICE on beta and nightly
I bisected the regression, here is the output of : searched nightlies: from nightly-2022-06-24 to nightly-2022-08-05 regressed nightly: nightly-2022-07-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
Out of these seems the most likely, cc
Zooming onto changeset.
Found MVCE: <details<summaryOutput from Rust Playground</summary</details
Change:
let is_pie_binary = !find_features && is_pie_binary(sess); let trap_unreachable = sess.target.target.options.trap_unreachable; <ins> let asm_comments = sess.asm_comments(); </ins> Arc::new(move || { let tm = unsafe { llvm::LLVMRustCreateTargetMachine(

Discussion:
clang -S produces nicely commented .s files. It would be nice if rustc did this too. e.g. simd shuffles are commented .loc directives have the corresponding line number comment .loc 1 4 25 isstmt 1 ## test.c:4:25 debug information is commented .byte 14 ## DWFORMstrp .byte 17 ## DWATlowpc .byte 1 ## DWFORMaddr .byte 18 ## DWAThighpc .byte 1 ## DWFORM_addr
There might be a or flag already for this. AFAIK what clang emits comes from LLVM.
This flag is already , should be usable (issue can be closed?):
Any reason not to make this the default?
Likely the fact that it may change the behavior (I don't actually know what that means but this seems like a valid assumption).
it looks like -Z asm-comments doesn't do this. MCOptions.AsmVerbose must be set to true for the assembler to emit them.
So it looks like -Zasm-comments isn't actually used anywhere based on what I can find in the source... or, rather, its uses are in methods that are themselves never called.
Yeah, to get comments I believe I needed to set a verbose flag in some llvm context. Clang does this by default and it would be nice if rustc did too.
IIUC without this neither the playground nor godbolt (compiler-explorer) can map assembly to lines of Rust source code.
Godbolt uses debug info AFAIK? Our debug info isn't always great but in general it's working, isn't it?
It seems like they just don't do it much. Godbolt uses directives in the assembly file, which rustc seems to generate correctly, sorry for the noise.