jiebi/CodeConvo huggingface dataset:
Change:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: named field access on non-ADT', 'error: internal compiler error: named field access on non-ADT' 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: 22 | let buf: &mut [*const dyn Foo] = &mut [&u8, &u8.0, &u32, &u32.0]; [livesymbolsandignoredderivedtraits] finding live symbols in crate [checkmod_deathness] checking deathness of variables in top-level module [analysis] running analysis passes on this crate --
mmh this bisects to cc

Discussion:
self.insert_def_id(def.non_enum_variant().fields[index].did); } ty::Tuple(..) => {} <del> _ => span_bug!(lhs.span, "named field access on non-ADT"), </del> <ins> ty::Error(_) => {} kind => span_bug!(lhs.span, "named field access on non-ADT: {kind:?}"), </ins> } }

<ins> trait Foo {} impl<T> Foo for T {} fn main() { let array = [(); { loop {} }]; //~ ERROR constant evaluation is taking a long time let tup = (7,); let x: &dyn Foo = &tup.0; } </ins>

<ins> error: constant evaluation is taking a long time --> $DIR/do-not-ice-on-field-access-of-err-type.rs:5:24 | LL |     let array = [(); { loop {} }]; |                        ^^^^^^^ | = note: this lint makes sure the compiler doesn't get stuck due to infinite loops in const eval. If your compilation actually takes a long time, you can safely allow the lint. help: the constant being evaluated --> $DIR/do-not-ice-on-field-access-of-err-type.rs:5:22 | LL |     let array = [(); { loop {} }]; |                      ^^^^^^^^^^^ = note: `#[deny(long_running_const_eval)]` on by default error: aborting due to 1 previous error </ins>
Change:
I have a linear algebra based project () which has a set of Scalar, Vector and Matrix traits that refer to each other via associated traits. On stable (rustc 1.77.1) this builds fine, but on beta (1.78.0) and nightly (1.79.0) the build hangs (). A MRE is: If I look at the compiler log with RUSTCLOG=TRACE I see an endless repitition of text like: Note that if I remove the trait everything builds fine. The bug does not exist in stable: : The bug exists in beta and nightly: : : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summaryBacktrace</summary<phere is some more of the logs: </p</details
IIUC that's from cc (it also only happens with the old solver ofc)
I'm fascinated that this wasn't fixed by . Perhaps there's somewhere else we need to be calling instead of in the solver...
Oh lol, I found the bug.

Discussion:
let Some(clause) = clause.as_projection_clause() else { return ControlFlow::Continue(()); }; <ins> if clause.projection_def_id() != obligation.predicate.def_id { return ControlFlow::Continue(()); } </ins> let is_match = selcx.infcx.probe(|_| selcx.match_projection_projections(obligation, clause, true));

<ins> //@ check-pass #![recursion_limit = "1024"] // Really high recursion limit ^ // Test that ensures we're filtering projections by def id before matching // them in `match_projection_projections`. use std::ops::{Add, Sub}; pub trait Scalar {} pub trait VectorCommon: Sized { type T: Scalar; } pub trait VectorOpsByValue<Rhs = Self, Output = Self>: VectorCommon + Add<Rhs, Output = Output> + Sub<Rhs, Output = Output> { } pub trait VectorView<'a>: VectorOpsByValue<Self, Self::Owned> + VectorOpsByValue<Self::Owned, Self::Owned> { type Owned; } pub trait Vector: VectorOpsByValue<Self> + for<'a> VectorOpsByValue<Self::View<'a>> { type View<'a>: VectorView<'a, T = Self::T, Owned = Self> where Self: 'a; } pub trait MatrixCommon { type V: Vector; } fn main() {} </ins>
Change:
No response This error is very confusing and unreadable, and the compiler even proposes adding a type containing a local path into the code. That seems very problematic and incorrect. No response No response
Try updating your nightly compiler and checking if it's still like that? You're using a nightly compiler from January.
To second compiler-errors' comment, I know that there was a change in this suggestion sometime in the past month. Edit: nevermind
Output with the PR linked above: We still need a minimal repro to add a test to the test suite.
Needs test.
Minimized reproduction in 1.77 nightly

Discussion:
<ins> // This is a regression test for #123630 // // Prior to #123703 this was resulting in compiler suggesting add a type signature // for `lit` containing path to a file containing `Select` - something obviously invalid. struct Select<F, I>(F, I); fn select<F, I>(filter: F) -> Select<F, I> {} //~^ 7:31: 7:43: mismatched types [E0308] fn parser1() { let lit = select(|x| match x { //~^ 11:23: 11:24: type annotations needed [E0282] _ => (), }); } fn main() {} </ins>

<ins> error[E0308]: mismatched types --> $DIR/dont-suggest-path-names.rs:7:31 | LL | fn select<F, I>(filter: F) -> Select<F, I> {} |    ------                     ^^^^^^^^^^^^ expected `Select<F, I>`, found `()` |    | |    implicitly returns `()` as its body has no tail or `return` expression | = note: expected struct `Select<F, I>` found unit type `()` error[E0282]: type annotations needed --> $DIR/dont-suggest-path-names.rs:11:23 | LL |     let lit = select(|x| match x { |                       ^        - type must be known at this point | help: consider giving this closure parameter an explicit type | LL |     let lit = select(|x: /* Type */| match x { |                        ++++++++++++ error: aborting due to 2 previous errors Some errors have detailed explanations: E0282, E0308. For more information about an error, try `rustc --explain E0282`. </ins>
Change:
We've recently begun testing Bevy against the beta toolchain, where it has incorrectly raised an lint against . is not imported in this file, yet rustdoc believes that it is. (See the imports .) As a temporary workaround, I've created to ignore the error. Here is that first failed. In case it expires, here's . Look at . I can reproduce it on using by running the following command: The is optional, but it makes the command finish quicker. I'll continue testing to see if I can create a minimum reproducible example. :
I've created a minimal reproduction in my -repro branch of my fork. Go to the  folder and run . I've managed to squish it down to this:
I've created a reproduction that removes the dependency on Bevy . I've simplified it down to this:
I bisected it, and this bug appears to first be introduced in . I could not reproduce it in .

Discussion:
use rustc_hir::def::{DefKind, DocLinkResMap, Namespace, Res}; use rustc_hir::HirId; use rustc_lint_defs::Applicability; <del> use rustc_resolve::rustdoc::source_span_for_markdown_range; </del> <ins> use rustc_resolve::rustdoc::{prepare_to_doc_link_resolution, source_span_for_markdown_range}; </ins> use rustc_span::def_id::DefId; use rustc_span::Symbol;

return; }; <del> let doc = item.doc_value(); if doc.is_empty() { return; } if let Some(item_id) = item.def_id() { check_redundant_explicit_link_for_did(cx, item, item_id, hir_id, &doc); } if let Some(item_id) = item.inline_stmt_id { check_redundant_explicit_link_for_did(cx, item, item_id, hir_id, &doc); </del> <ins> let hunks = prepare_to_doc_link_resolution(&item.attrs.doc_strings); for (item_id, doc) in hunks { if let Some(item_id) = item_id.or(item.def_id()) && !doc.is_empty() { check_redundant_explicit_link_for_did(cx, item, item_id, hir_id, &doc); } </ins> } }

<ins> //@ check-pass #![deny(rustdoc::redundant_explicit_links)] mod bar { /// [`Rc`](std::rc::Rc) pub enum Baz {} } pub use bar::*; use std::rc::Rc; /// [`Rc::allocator`] [foo](std::rc::Rc) pub fn winit_runner() {} </ins>
Change:
<!-- 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. --This bug is spotted jointly by and We tried this code (minimized by and I expected to see this happen: The program should exit without error. Instead, this happened: segmentation fault. Notice that the code will pass . (). The error is reproducible with larger than . The error seems to be related, as does not reproduce the bug. There seems to be no bug in LLVM IR. noticed that produces different asm compared with the one in the ELF output. Notice that we encountered an ICE while exploring the code (for now, we are not sure whether the ICE is related to SEGV, we can file a separate report for ICE if needed). Basically, invoking the rustc consecutively, one will get (cleaning up the directory can help): <!-- 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. --Both nightly and stable versions are affected :
may be running into
This started on stable in 1.73, and bisects to : A couple notes, when using cargo: incremental compilation is not enabled on release builds for people who opt into optimizing dependencies even in debug builds: incremental compilation is not enabled for dependencies either, only local crates It would be interesting to see exactly what impacts codegen here when enabling incremental compilation of a single session (but at the same time, it seems probable that not many users should encounter this issue in the more common configurations?).
Some additional context: the code is largely related to ecow. In case people compile typst/ecow related code with incremental build and level 1 optimization enabled and run into segmentation fault, this should be the bug behind it.
So the error happens just from adding , without there actually being a previous incremental cache there? Wow. Cc Seems likely that the LLVM 17 update is involved. Cc
I can confirm that this reproduces with an empty cache -- which should be good news in terms of debugging the issue. I'm pretty sure this is a ThinLTO-related bug and incremental somehow configures CGUs and LLVM settings in a way that triggers the bug. The segfault does not reproduce when compiling with .
Running the miscompiled binary in gdb (with ) gives:
Yeah, that would crash...
I think this is a minimal reproducer: We infer that the result of this function is nonnull...
Upstream issue:
WG-prioritization assigning priority (). label -I-prioritize +P-high

Discussion:
[submodule "src/llvm-project"] path = src/llvm-project url = https://github.com/rust-lang/llvm-project.git <del> branch = rustc/18.0-2024-02-13 </del> <ins> branch = rustc/18.1-2024-05-19 </ins> shallow = true [submodule "src/doc/embedded-book"] path = src/doc/embedded-book

<del> Subproject commit 5399a24c66cb6164cf32280e7d300488c90d5765 </del> <ins> Subproject commit b31c30a9bb4dbbd13c359d0e2bea7f65d20adf3f </ins>
Change:
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.

Discussion:
/// tokens. UnknownPrefix, <ins> /// Similar to the above, but *always* an error on every edition. This is used /// for emoji identifier recovery, as those are not meant to be ever accepted. InvalidPrefix, </ins> /// Examples: `12u8`, `1.0e-40`, `b"123"`. Note that `_` is an invalid /// suffix, but may be present here on string and float literals. Users of /// this type will need to check for and reject that case.

// Known prefixes must have been handled earlier. So if // we see a prefix here, it is definitely an unknown prefix. match self.first() { <del> '#' | '"' | ''' => UnknownPrefix, </del> <ins> '#' | '"' | ''' => InvalidPrefix, </ins> _ => InvalidIdent, } }

self.ident(start) } rustc_lexer::TokenKind::InvalidIdent <ins> | rustc_lexer::TokenKind::InvalidPrefix </ins> // Do not recover an identifier with emoji if the codepoint is a confusable // with a recoverable substitution token, like `➖`. if !UNICODE_ARRAY

rustc_lexer::TokenKind::Caret => token::BinOp(token::Caret), rustc_lexer::TokenKind::Percent => token::BinOp(token::Percent), <del> rustc_lexer::TokenKind::Unknown | rustc_lexer::TokenKind::InvalidIdent => { </del> <ins> rustc_lexer::TokenKind::Unknown | rustc_lexer::TokenKind::InvalidIdent | rustc_lexer::TokenKind::InvalidPrefix => { </ins> // Don't emit diagnostics for sequences of the same invalid token if swallow_next_invalid > 0 { swallow_next_invalid -= 1;

}, 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"), };

rustc_lexer::TokenKind::Ident => { SyntaxKind::from_keyword(token_text).unwrap_or(IDENT) } <del> rustc_lexer::TokenKind::InvalidIdent => { </del> <ins> rustc_lexer::TokenKind::InvalidPrefix | rustc_lexer::TokenKind::InvalidIdent => { </ins> err = "Ident contains invalid characters"; IDENT }

<ins> macro_rules! lexes {($($_:tt)*) => {}} lexes!(🐛#); //~ ERROR identifiers cannot contain emoji lexes!(🐛"foo"); lexes!(🐛'q'); lexes!(🐛'q); fn main() {} </ins>

<ins> error: identifiers cannot contain emoji: `🐛` --> $DIR/emoji-literal-prefix.rs:3:8 | LL | lexes!(🐛#); |        ^^ LL | lexes!(🐛"foo"); |        ^^ LL | lexes!(🐛'q'); |        ^^ LL | lexes!(🐛'q); |        ^^ error: aborting due to 1 previous error </ins>
Change:
This bug only happens when calling a method on two different referenced variables inside an async closure. For some reason, this bug will not happen if the lines are flipped (calling it on test first then temp). It also will not happen if test isn't cloned outside the closure first. This will error: This will not: Neither will: Nor will: But if both the order is flipped and the line order is flipped it will crash (variable name changed to make sure shadowing wasn't the issue): This setup for the bug was found entirely through trial and error. The original issue was found in a nightly build of a project I'm working on (). This bug was introduced in the latest version of nightly (2024-04-08). It was not present in 2024-04-07. rustc 1.79.0-nightly ( 2024-04-08) binary: rustc commit-hash: commit-date: 2024-04-08 host: x8664-pc-windows-msvc release: 1.79.0-nightly LLVM version: 18.1.3 ICE txt file:
thank you for producing these examples; they're very helpful. i will have a fix out tomorrow, sorry for the inconvenience and hope it doesn't discourage you from testing async closures more.
Wow, that was quick! Thanks, I'll make sure to report any more I come across, I plan on implementing more async closures into the project with my next big refactor because of how helpful they are.

Discussion:
}) { let (child_field_idx, child_capture) = child_captures.next().unwrap(); <ins> // This analysis only makes sense if the parent capture is a // prefix of the child capture. assert!( child_capture.place.projections.len() >= parent_capture.place.projections.len(), "parent capture ({parent_capture:#?}) expected to be prefix of  child capture ({child_capture:#?})" ); </ins> // Store this set of additional projections (fields and derefs). // We need to re-apply them later. let child_precise_captures =

bug!("expected capture to be an upvar"); }; <del> assert!(child_capture.place.projections.len() >= parent_capture.place.projections.len()); </del> parent_base.var_path.hir_id == child_base.var_path.hir_id && std::iter::zip(&child_capture.place.projections, &parent_capture.place.projections) .all(|(child, parent)| child.kind == parent.kind)

<ins> //@ check-pass //@ edition: 2021 // issue: rust-lang/rust#123697 #![feature(async_closure)] struct S { t: i32 } fn test(s: &S, t: &i32) { async || { println!("{}", s.t); println!("{}", t); }; } fn main() {} </ins>
Change:
Hello, regressed on the following tests on MIPS: I have bisected this to in the Rust repo and to in the LLVM repo. (On Debian 12) install a MIPS toolchain: a file with the following contents (which is a simplified snippet of the failing doctests mentioned above): it like this: like this: The program completes successfully. The program fails like this: With pointing to the test also fails, but when pointing to the parent commit () the test passes. So we can conclude that this regression was introduced by , which originates from Edit: See for more discussion around this. label +O-MIPS +A-atomic +T-compiler +C-bug
label +A-LLVM
I can confirm that the regression has been fixed :+1: The first nightly with the fix is nightly-2024-04-19.

Discussion:
<del> Subproject commit af8f9eb61a2ad4ee1f2d3f46d157b93a47c6a4bf </del> <ins> Subproject commit 5399a24c66cb6164cf32280e7d300488c90d5765 </ins>
Change:
From The Rust Reference Manual; However, NFKC requires to transform some characters into different ones even in strings or comments and then we will get different results on such cases. Even NFC have some problems if we have to preserve a text strictly. (yes, the word different is ambiguous; in NFKC, they are treated as the same, but the glyphs of them are different... sometimes depends on the font, though) I'd suggest to remove the "normalized to NFKC" clause and leave the input, like golang. From The Go Programming Language Specification:
We actually don't do any normalization of source input right now, the manual is just plain wrong in claiming it. A PR removing that sentence would probably be welcomed.
the text requires that we, programmers, must normalize our source code before the compilation IMHO, so I would ask whether it is really needed.
That's not what the manual is saying, the manual is saying that it normalizes input. We haven't decided if normalizing input is the correct thing to do yet, though. , OGINO Masanori :
Thank you for clarifying. Why is the spec saying so?
probably because there is precedent in other languages for doing such normalization, at least for identifiers. (Though if the spec implies doing it in string constants, then that is probably just sloppiness in the writing of the spec.) Related bug: update: To clarify, graydon originally wanted to do NFKC normalization in the lexer (as noted in the bug above), but he changed his mind and so we have been in a bit of a state of limbo ever since. But as I said above, the scope of that normalization was, I think, intended to be restricted to identifiers, not all lexical syntax (i.e. not the interior of string constants).
Thank you. I agree on the normalization for identifiers. I think it is acceptable. Certainly some similar but different identifiers treated as the same ones, but we should not do such cheat. (NFKC vs. NFC problem remains, though) I think it is good to update the spec to specify that we may normalize identifiers for ease of comparison/collation.

Discussion:
## Input format <del> Rust input is interpreted as a sequence of Unicode codepoints encoded in UTF-8, normalized to Unicode normalization form NFKC. </del> <ins> Rust input is interpreted as a sequence of Unicode codepoints encoded in UTF-8. </ins> Most Rust grammar rules are defined in terms of printable ASCII-range codepoints, but a small number are defined in terms of Unicode properties or explicit codepoint lists. [^inputformat]
Change:
<!-- [31mICE[0m: Rustc '-Zcrate-attr=feature(unsizedfnparams) --crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'unsized arguments must not be types'', 'thread 'rustc' panicked at 'unsized arguments must not be types'' 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: [fnabiofinstance] computing call ABI of --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2020-10-29 fetching (via remote github) commits from max(, 2020-10-26) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 7 commit[0] 2020-10-27: Auto merge of - ayrtonm:function-reference-lint, r=oli-obk commit[1] 2020-10-27: Auto merge of - nathanwhit:cstring-temp-lint, r=oli-obk commit[2] 2020-10-28: Auto merge of - Dylan-DPC:rollup-tan044s, r=Dylan-DPC commit[3] 2020-10-28: Auto merge of - est31:smallerlistoverlap, r=varkor commit[4] 2020-10-28: Auto merge of - pietroalbini:build-manifest-checksum-cache, r=Mark-Simulacrum commit[5] 2020-10-28: Auto merge of - nox:function-sections, r=nagisa,bjorn3 commit[6] 2020-10-28: Auto merge of - tgnottingham:expnidtag_hash, r=Aaron1011 I guess
claim
Looks like this is WONTFIX while the features remain experimental (see ). release-assignment
Yeah, this is a deliberate ICE since a better error requires too much refactoring, and the fundamental issue is that this entire feature was never properly designed and poorly interacts with many other parts of the language. The fix is to mark unsizedfnparams as an internal feature, to warn people about the ICEs lurking here.
Or maybe it is extern types that should be marked as incomplete, they are causing trouble in many ways as nobody ever prepared Rust for types whose size cannot be determined dynamically...

Discussion:
/// Allows unsafe on extern declarations and safety qualifiers over internal items. (unstable, unsafe_extern_blocks, "1.80.0", Some(123743)), /// Allows unsized fn parameters. <del> (unstable, unsized_fn_params, "1.49.0", Some(48055)), </del> <ins> (internal, unsized_fn_params, "1.49.0", Some(48055)), </ins> /// Allows unsized rvalues at arguments and parameters. (incomplete, unsized_locals, "1.30.0", Some(48055)), /// Allows unsized tuple coercion.