jiebi/CodeConvo huggingface dataset:
Code change:
[[package]] name = "compiler_builtins" <del> version = "0.1.114" </del> <ins> version = "0.1.117" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "eb58b199190fcfe0846f55a3b545cd6b07a34bdd5930a476ff856f3ebcc5558a" </del> <ins> checksum = "a91dae36d82fe12621dfb5b596d7db766187747749b22e33ac068e1bfc356f4a" </ins> dependencies = [ "cc", "rustc-std-workspace-core",

Related discussion:
text: I do not have minimised code. This was a sudden CI build failure on nightly for aarch64-unknown-linux-musl () Note that this is a cross compile using cross-rs. It fails on rust version 1.82.0-nightly ( 2024-07-29) but works on 1.82.0-nightly ( 2024-07-28). Needless to say it also works perfectly fine on stable. The error is reproducible on rebuild and locally with cross-rs. It is not reproducible with cargo-zigbuild interestingly enough. I also checked that the version of cross-rs didn't change between the successful and failing builds (no new releases of that project since february). The only change between the successful and failing CI runs were a typo fix to an unrelated CI pipeline (the release one, so it didn't even run yet). As such I'm forced to conclude that the blame lies with Rustc. Steps to reproduce: I expected to see this happen: Compilation successful (as it is with stable for same target, or with -gnu and nightly) Instead, this happened () It most recently worked on: 1.82.0-nightly ( 2024-07-28) (or stable 1.80.0 or beta 1.81.0, take your pick for triaging) :
cc (of cross-rs fame) in case he has any insight on this regression
I have hit the same issue in a similar situation. Cross compiling to aarch64-unknown-linux-musl from x86_64 linux in a Github CI pipeline using cross-rs. Link to pipeline failing logs:
Seems rune isn't needed based on the comment by Updated the title.
This is probably
WG-prioritization assigning priority (). label -I-prioritize +P-high
Yeah that's probably it. We used to build the C version of those symbols but switched to Rust versions with the compiler builtins update. Unfortunately we can't enable them on all platforms because LLVM has crashes, and the logic that would allow optional configuration is apparently not working.
Code change:
[[package]] name = "compiler_builtins" <del> version = "0.1.114" </del> <ins> version = "0.1.117" </ins> source = "registry+https://github.com/rust-lang/crates.io-index" <del> checksum = "eb58b199190fcfe0846f55a3b545cd6b07a34bdd5930a476ff856f3ebcc5558a" </del> <ins> checksum = "a91dae36d82fe12621dfb5b596d7db766187747749b22e33ac068e1bfc356f4a" </ins> dependencies = [ "cc", "rustc-std-workspace-core",

Related discussion:
text: After that part is fixed, we will need to enable the symbols on all platforms where is f128 (which includes aarch64), since these errors probably come from here I think anyone who needs a quick workaround can add to their dependencies to get the symbols directly, as described near the top of Note that this requires nightly.
Is it possible to add a dependency conditionally based on if it is nightly? (In a specific range of dates even?) I cannot and will not depend on nightly, but I do test my code on nightly in CI (in order to find breakages like this early). For now I just disabled that nightly build on aarch64 musl.
Same for me. Not using cross-rs though. Logs are here:
Same for me, both using as host toolchain and cross compiling.
Looks like it is happening now too for x86_64.
Not for my projects, so you should probably provide a reproducer on x86-64 GNU if possible, since that is a tier 1 platform (unlike Aarch64 on Musl). Or is this about some other x8664 variation that is also tier 2?
Woops, sorry, the x86_64 build failed too, but then i looked at the aarch64 build logs :) which still fail.
Code change:
} match self.parse_expr_res(Restrictions::CONST_EXPR, None) { Ok(expr) => { <del> if token::Comma == self.token.kind || self.token.kind.should_end_const_arg() { </del> <ins> // Find a mistake like `MyTrait<Assoc == S::Assoc>`. if token::EqEq == snapshot.token.kind { err.span_suggestion( snapshot.token.span, "if you meant to use an associated type binding, replace `==` with `=`", "=".to_string(), Applicability::MaybeIncorrect, ); let value = self.mk_expr_err(start.to(expr.span)); err.emit(); return Ok(GenericArg::Const(AnonConst { id: ast::DUMMY_NODE_ID, value })); } else if token::Comma == self.token.kind || self.token.kind.should_end_const_arg() { </ins> // Avoid the following output by checking that we consumed a full const arg: // help: expressions must be enclosed in braces to be used as const generic //       arguments

Related discussion:
text: <!-- 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: Playground: I expected to see this happen: The error message should indicate that the should be a single . Instead, this happened: The error message gives no hint of the correct syntax. It gives two errors, neither of which are helpful: This error is unhelpful because it says "expected one of or ", but is also allowed. Also, the suggestion to use curly braces is a red herring. This error is unhelpful because I am not specifying const arguments; I'm specifying associated types. Rust version according to 1.53.0
cc
Code change:
LL |     f: i32, |     ^^^^^^ <del> error: aborting due to 3 previous errors </del> <ins> error: field is never read: `y` --> $DIR/write-only-field.rs:28:9 | LL |         y: bool, |         ^^^^^^^ error: field is never read: `u` --> $DIR/write-only-field.rs:58:9 | LL |         u: u32, |         ^^^^^^ error: field is never read: `v` --> $DIR/write-only-field.rs:59:9 | LL |         v: u32, |         ^^^^^^ error: aborting due to 6 previous errors </ins>

Related discussion:
text: <!-- 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. --Here's a reduced test-case from Firefox source code: Compiling that program warns with: Which is obviously not true. <!-- 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. --:
Seems like this is a regression from .
cc
Oops, sorry! Technically, field is, in fact, never read. What went wrong is is written and read through other ways. I think restricting the lint to non-reference fields should work, and will submit a PR to do so quickly. Please double check whether my thinking is correct.
Ah, yeah, I somehow thought that the macro was needed to trigger the bug but it is not. That sounds good. Writes to mutable references have side effects so doing that seems ok.
Would that also cover this case here, in the idna crate? (The field is a reference to an type, which is in fact returned to the caller of .)
Yeah, I think it's the same.
Ah, this was closed, but the bug leaked into beta (as mentioned in ) while the fix is only in nightly. Reopening and tagging as stable-to-beta regression
Assigning and removing .
As noted on , we're going to resolve the beta issue by reverting PR on beta (which I have assigned myself to take care of).
This was a regression affecting beta 1.51, closing this.
Code change:
&ccx.int_type); let llfn = decl_cdecl_fn(ccx, "main", llfty, ty::mk_nil()); <ins> // FIXME: #16581: Marking a symbol in the executable with `dllexport` // linkage forces MinGW's linker to output a `.reloc` section for ASLR if ccx.sess().targ_cfg.os == OsWindows { unsafe { llvm::LLVMRustSetDLLExportStorageClass(llfn) } } </ins> let llbb = "top".with_c_str(|buf| { unsafe { llvm::LLVMAppendBasicBlockInContext(ccx.llcx, llfn, buf)

Related discussion:
text: This should be as simple as passing to the linker for both libraries and executables. However, the necessary relocations are never generated by MinGW or MinGW-w64 for executables so nothing is actually randomized without also passing . The switch is also broken and results in a messed up entry point, but it may not actually be required.
Hi, I found this issue while looking for an old reference, but I thought you might be interested in a possible fix. We needed for Tor's hardening options and after some back and forth settled on a working binutils patch which is here (works for 2.24 and is being submitted upstream shortly): This patch has not been reviewed at all, since no one at Tor feels sufficiently capable. Hopefully the binutils folks will have something to say, but as language developers you might too. (edit: fix link to patch)
We ended up working around it for the time being by doing a dllexport of main in order to force it to output a relocation section, since the executable counts as a library. I would really like to have this fixed properly though so I'll look into it some more when I have time.
Needs to be disabled again due to .
Note that recent binutils may have support for high entropy ASLR. ( was accepted last year. See ) It would be good to check if mingw-w64 would contain the patch when we re-enable ASLR.
Triage: not sure if anything has changed here, but I don't think so.
Triage: same as in 2016
Code change:
<ins> error[E0425]: cannot find value `a` in this scope --> $DIR/format-args-capture-issue-102057.rs:2:18 | LL |     format!("x7Ba}"); |                  ^ not found in this scope error[E0425]: cannot find value `a` in this scope --> $DIR/format-args-capture-issue-102057.rs:4:18 | LL |     format!("x7Bax7D"); |                  ^ not found in this scope error[E0425]: cannot find value `b` in this scope --> $DIR/format-args-capture-issue-102057.rs:9:22 | LL |     format!("x7Ba} {b}"); |                      ^ help: a local variable with a similar name exists: `a` error[E0425]: cannot find value `b` in this scope --> $DIR/format-args-capture-issue-102057.rs:11:25 | LL |     format!("x7Bax7D {b}"); |                         ^ help: a local variable with a similar name exists: `a` error[E0425]: cannot find value `b` in this scope --> $DIR/format-args-capture-issue-102057.rs:13:25 | LL |     format!("x7Ba} x7Bb}"); |                         ^ help: a local variable with a similar name exists: `a` error[E0425]: cannot find value `b` in this scope --> $DIR/format-args-capture-issue-102057.rs:15:28 | LL |     format!("x7Bax7D x7Bb}"); |                            ^ help: a local variable with a similar name exists: `a` error[E0425]: cannot find value `b` in this scope --> $DIR/format-args-capture-issue-102057.rs:17:28 | LL |     format!("x7Bax7D x7Bbx7D"); |                            ^ help: a local variable with a similar name exists: `a` error: aborting due to 7 previous errors For more information about this error, try `rustc --explain E0425`. </ins>

Related discussion:
text: I tried this code: I expected to see this happen: a "no value found" error pointing at the token Instead, this happened: a "no value found" error pointing at the : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This doesn't seem to be an issue on stable, interestingly.
Yep, it works fine on 1.63.0, but has the problem on 1.65.0-beta.1 and the latest nightly.
claim
Code change:
self.draw_line( &mut buffer, <del> &unannotated_line, </del> <ins> &replace_tabs(&unannotated_line), </ins> annotated_file.lines[line_idx + 1].line_index - 1, last_buffer_line_num, width_offset,

Related discussion:
text: The code that truncates long lines doesn't take (hard) tabs into account, so the lines printed are off. Example code: Gives the following error: If you use four spaces instead of each tab it works as expected: cc and cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I thought we were already accounting for tabs, but looking we rely on which considers to not have a width, which we then assume to be 1.
claim
Code change:
LifetimeRibKind::Item | LifetimeRibKind::AnonymousReportError | LifetimeRibKind::ElisionFailure => Some(LifetimeUseSet::Many), <del> // An anonymous lifetime is legal here, go ahead. LifetimeRibKind::AnonymousCreateParameter { .. } => { Some(LifetimeUseSet::One { use_span: ident.span, use_ctxt }) } </del> <ins> // An anonymous lifetime is legal here, and bound to the right // place, go ahead. LifetimeRibKind::AnonymousCreateParameter { binder: anon_binder, .. } => Some(if binder == anon_binder { LifetimeUseSet::One { use_span: ident.span, use_ctxt } } else { LifetimeUseSet::Many }), </ins> // Only report if eliding the lifetime would have the same // semantics. LifetimeRibKind::Elided(r) => Some(if res == r {

Related discussion:
text: <!-- 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: : I expected to see this happen: explanation suggestion compiles: Instead, this happened: explanation Suggestion does not compile: ` <!-- 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. --:
Code change:
}; ExprKind::Cast { source } <ins> } else { // Default to `ExprKind::Cast` for all explicit casts. // MIR building then picks the right MIR casts based on the types. ExprKind::Cast { source: self.mirror_expr(source) } </ins> } }

Related discussion:
text: <!-- 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: . I expected to see this happen: it compiles, since raw pointer casts should be allowed even for completely different types. Instead, this happened: it fails with: It looks like for some reason the compiler creates a lifetime obligation here. Strangely, it works with : .
I've looked into this. The issue is that typeck considers this cast to be a "coercion cast", because typeck thinks that you could replace the function body with just since the types are the same (it also triggers the lint (allow-by-default)). HIR typeck isn't aware of lifetimes. So then THIR building and MIR building build MIR that doesn't contain a cast but instead just assigns one to the other. The borrow checker is rightfully not pleased. The bug here is that the THIR does not contain an explicit cast anymore. I'm not sure how to best fix this, as the current logic for "is this a no-op cast (called coercion cast in the code)" is just "try to coerce the types in the same way that happens on coercion sites and if it works it has to be useless". Which is wrong in the presence of lifetimes. It seems like the current strategy works this way because it reuses some code in THIR building. Thinking about it a little more, this is very special to pointer casts, because only pointer casts are allowed to change the type like this. Maybe THIR building should just special case pointer casts to always be emitted?
Unfortunately due to this bug there is that should be turned into a raw pointer cast, but we cannot.
I think that's a different case, these are boxes and not raw pointers, and box-box casts are not allowed to do arbitrary changes (and are in fact coercion casts, so the doesn't actually do anything). The error there is correct and this needs a transmute.
I'd like to replace the transmutes by raw pointer casts, which IMO is much preferable, similar to But this bug is in the way of that.
Code change:
<del> // check-pass </del> // aux-build:import_crate_var.rs #[macro_use] extern crate import_crate_var; fn main() { m!(); <del> //~^ WARN `$crate` may not be imported //~| NOTE `use $crate;` was erroneously allowed and will become a hard error </del> <ins> //~^ ERROR `$crate` may not be imported </ins> }

Related discussion:
text: The warning was introduced in to avoid breakage from .
Presumably the next step is to make this an error by default.
Triage: Digging through all the linked issues is tough, and it's not clear to me exactly what this warning is or does. can you maybe elaborate a little?
This needs to be turned into an error, i.e. behave like basically:
Relevant code is here: Should be easy to turn that into and then do a crater run.
Code change:
); // print the suggestion draw_col_separator(&mut buffer, row_num, max_line_num_len + 1); <del> buffer.append(row_num, line, Style::NoStyle); </del> <ins> buffer.append(row_num, &replace_tabs(line), Style::NoStyle); </ins> row_num += 1; }

Related discussion:
text: The code that truncates long lines doesn't take (hard) tabs into account, so the lines printed are off. Example code: Gives the following error: If you use four spaces instead of each tab it works as expected: cc and cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I thought we were already accounting for tabs, but looking we rely on which considers to not have a width, which we then assume to be 1.
claim
Code change:
<ins> fn main() { let str::<{fn str() { let str::T>>::as_bytes; }}, T>::as_bytes; //~^ ERROR expected a pattern, found an expression //~| ERROR cannot find type `T` in this scope //~| ERROR type and const arguments are not allowed on builtin type `str` //~| ERROR expected unit struct, unit variant or constant, found associated function `str<, T>::as_bytes` } </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'error: internal compiler error: node HirId(DefId(0:32 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments::{constant}::checktrybindstighter).22) (pat ) cannot be placed in TypeckResults with hirowner DefId(0:22 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments)', 'error: internal compiler error: node HirId(DefId(0:32 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments::{constant}::checktrybindstighter).22) (pat ) cannot be placed in TypeckResults with hirowner DefId(0:22 ~ 787F2C645D84C34B503984769364221101FF5A50720AF027A7CACDC71EA4474E[c98a]::insideconstgenericarguments)' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: [typeck] type-checking [analysis] running analysis passes on this crate --
This bisects to cc
Code change:
use rustc_middle::mir::ConstraintCategory; use rustc_middle::traits::query::OutlivesBound; use rustc_middle::ty::{self, RegionVid, Ty}; <del> use rustc_span::{Span, DUMMY_SP}; </del> <ins> use rustc_span::{ErrorGuaranteed, Span, DUMMY_SP}; </ins> use rustc_trait_selection::traits::query::type_op::{self, TypeOp}; use std::rc::Rc; use type_op::TypeOpOutput;

Related discussion:
text: 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
Regression in cc :sweat_smile:
I knew this was a source of ICEs Most of these should already be reachable if they are in the body of a constant used in an array length. If you want to try fuzzing by sticking code into a const body...
Code 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. fn blah() -> int { //~ ERROR not all control paths return a value 1i ; //~ NOTE consider removing this semicolon: } fn main() { } </ins>

Related discussion:
text: Here is the error Here is the code that generates the error My system is x86_64 archlinux. The rust compiler version is Let me know if you guys need anything else. (The code is really short so it shouldn't be hard to just type it in to duplicate the bug)
It only needs one line for me
Workaround (in the sense that the compiler no longer ICE's): I think there is some unfortunate interaction here with the way we attempt to infer which kind of numeric literals are in the array (, , etc) and other code not being prepared to handle the that results when you don't have that information available.
This is almost certainly a duplicate of (but maybe the integer inference codepath is slightly different?).
This also causes the same ICE -
Similarly:
Looks like it's been fixed.
Code 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. fn blah() -> int { //~ ERROR not all control paths return a value 1i ; //~ NOTE consider removing this semicolon: } fn main() { } </ins>

Related discussion:
text: Swapping the order of the branches compiles fine. cc
Just checked: this fails with a normal closure too, not just a proc.
Compiles fine now but potentially needs a test.
Code 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. fn blah() -> int { //~ ERROR not all control paths return a value 1i ; //~ NOTE consider removing this semicolon: } fn main() { } </ins>

Related discussion:
text: Versions: Code to reproduce the ICE: Compilation output:
Seems to be fine now but potentially needs a test.
Nope, still failing. An updated example:
That code example fails to compile, but it's because the function signature for is wrong. It should be: When you make that change and make the struct fields public, the code compiles fine. Without the change I also didn't see any internal compiler errors. Rust Version: 0.12.0-pre-nightly, , Linux x8664
Yeah, I think this can be closed.
Flagging as needstest (not sure if one is checked in already)
Code 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. fn blah() -> int { //~ ERROR not all control paths return a value 1i ; //~ NOTE consider removing this semicolon: } fn main() { } </ins>

Related discussion:
text: It gives
cc
Looks like it no longer causes an ICE.
I agree, it is fixed, I close it.