jiebi/CodeConvo huggingface dataset:
Change:
trans.gen(*index); } <ins> // Make sure there are no remaining borrows for variables // that are assigned over. self.kill_borrows_on_place(trans, lhs); </ins> } mir::StatementKind::StorageDead(local) => {

Discussion:
Hey Folks, So, I've been fuzz testing nightly using a range of generated programs and am digesting the findings. This one stood out to me: This currently reports an E0505 on the playground and Rust nightly. However, removing the nop and its fine. This feels like a bug to me ... thoughts?
I think this is technically a reborrow () rather than a no-op, because the lhs and rhs are both known to be . Though this might be the first time I've ever seen a reborrow cause fewer programs to compile versus a move! (amusingly, though, the MIR is simply ) Edit: nope, there's more to it than that. If you explicitly write , it compiles!
Ok, have found some more related cases: Above gives and . Above gives and .
Discussed in lang team pre-triage meeting. Maybe you'd be game to investigate and take a look at what's happening here?
Change:
// where `*.pdb` files show up next to the final artifact. split_debuginfo: SplitDebuginfo::Packed, supported_split_debuginfo: Cow::Borrowed(&[SplitDebuginfo::Packed]), <ins> debuginfo_kind: DebuginfoKind::Pdb, </ins> ..Default::default() }

Discussion:
The UEFI targets (x8664-unknown-uefi, i686-unknown-uefi, and aarch64-unknown-uefi) started failing to compile in the latest nightly when using , failing with "LLVM ERROR: dwo only supported with ELF and Wasm". : : Build: searched nightlies: from nightly-2022-08-25 to nightly-2022-08-27 regressed nightly: nightly-2022-08-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsCC since bisect pointed to
Can confirm. Definitely needs to be looked into by the team — can you reproduce this?
I see in that is set in . I think that needs to be in , or maybe directly in ? I tested this out locally by using a custom target JSON that matches except adds , and that seems to fix the bug.
Change:
); err.span_label(self.span, "invalid cast"); if self.expr_ty.is_numeric() { <del> err.span_help( self.span, if self.expr_ty == fcx.tcx.types.i8 { "try casting from `u8` instead" } else if self.expr_ty == fcx.tcx.types.u32 { "try `char::from_u32` instead" } else { "try `char::from_u32` instead (via a `u32`)" }, ); </del> <ins> if self.expr_ty == fcx.tcx.types.u32 { match fcx.tcx.sess.source_map().span_to_snippet(self.expr.span) { Ok(snippet) => err.span_suggestion( self.span, "try `char::from_u32` instead", format!("char::from_u32({snippet})"), Applicability::MachineApplicable, ), Err(_) => err.span_help(self.span, "try `char::from_u32` instead"), }; } else if self.expr_ty == fcx.tcx.types.i8 { err.span_help(self.span, "try casting from `u8` instead"); } else { err.span_help(self.span, "try `char::from_u32` instead (via a `u32`)"); }; </ins> } err.emit(); }

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 is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Et Voila! ! Here's the final result, pushing a PR soon
Should be fixed by
Change:
use core::default::Default; use core::fmt; use core::hash::{self, Hash}; <ins> use core::intrinsics::assume; </ins> use core::iter::{repeat, FromIterator, IntoIterator}; use core::marker::{self, ContravariantLifetime, InvariantType}; use core::mem;

Discussion:
Consider the following benchmark: Which produces the following output: test _range ... bench: ns/iter (+/- 1033) test assembly ... bench: ns/iter (+/- 248) test enumerate ... bench: ns/iter (+/- 566) test iter ... bench: ns/iter (+/- 465) test position ... bench: ns/iter (+/- 384) is the correct abstraction for this but its code is 50% slower than the naive assembly implementation and 40% slower than .
I'm getting different results: $ rustc --opt-level=3 --test $ ./slowposition --bench running 4 tests test _range ... bench: ns/iter (+/- 8183) test enumerate ... bench: ns/iter (+/- 1615) test iter ... bench: ns/iter (+/- 4164) test position ... bench: ns/iter (+/- ) test result: ok. 0 passed; 0 failed; 0 ignored; 4 measured (the assembly version segfaulted on me).
wow. What platform?
On a macbook. Here's another run without a bunch of stuff in the background screwing up the variance: $ rustc --opt-level=3 --test $ ./slowposition --bench running 4 tests test _range ... bench: ns/iter (+/- 2331) test enumerate ... bench: ns/iter (+/- 2851) test iter ... bench: ns/iter (+/- 3995) test position ... bench: ns/iter (+/- 978)
The IL for -s inner loop is (de-gensymmed) Which looks sane, except for the spurious null check (which remains in the assembly). Benchmarks on my machine:
The spurious null check is the issue – writing a over it in the object code gives ±385 ns/iter on my laptop.
New code: New results: Unacceptable performance.
Change:
unsatisfied_const: bool, ) { let body_def_id = obligation.cause.body_id; <ins> let span = if let ObligationCauseCode::BinOp { rhs_span: Some(rhs_span), .. } = obligation.cause.code() { *rhs_span } else { span }; </ins> // Try to report a help message if is_fn_trait && let Ok((implemented_kind, params)) = self.type_implements_fn_trait(

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 (while debugging): Where is the corresponding type from the crate (and everything else is my types). It has an associated function , which returns a 16-byte slice containing the UUID. Because the right-hand-side of the comparison is not a byte slice but an array, the two expressions can't be compared and I get error E0277, shown below. Of interest is the help message at the end, which has the correct solution, but proposes a fix with invalid syntax. It should suggest placing before . <!-- 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 could not test on nightly, as I got a different compile error, apparently related to procedural macros: <details<summaryError</summary<p</p</details
For the error, see . Could you try to bump your version? Also, could you maybe provide either the full code or a smaller reproduction of the suggestion (if possible), I can't seem to reproduce the suggestion for your pattern on stable.
Thanks for the notice. I just bumped to and retried on nightly: Unfortunately the exact same misleading help message still appears. I managed to reproduce it here: The import or argument is actually necessary to cause the bug. If you remove both, the help message doesn't appear. Perhaps this is related to the crate, which I noticed uses a type alias called (), unrelated to .
Smaller repro but still requires dependency: Am investigating how to get rid of the dependency.
Repro without dependencies:
Change:
--> $DIR/cast-rfc0401.rs:41:13 | LL |     let _ = 0x61u32 as char; <del> |             ^^^^^^^^^^^^^^^ invalid cast | help: try `char::from_u32` instead --> $DIR/cast-rfc0401.rs:41:13 | LL |     let _ = 0x61u32 as char; </del> |             ^^^^^^^^^^^^^^^ <ins> |             | |             invalid cast |             help: try `char::from_u32` instead: `char::from_u32(0x61u32)` </ins> error[E0606]: casting `bool` as `f32` is invalid --> $DIR/cast-rfc0401.rs:43:13

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 is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Et Voila! ! Here's the final result, pushing a PR soon
Should be fixed by
Change:
# Only run the stage 1 tests on merges, not on PR CI jobs. if [[ -z "${PR_CI_JOB}" ]]; then <del> ../x.py --stage 1 test --skip src/tools/tidy &&  # Run the `mir-opt` tests again but this time for a 32-bit target. # This enforces that tests using `// EMIT_MIR_FOR_EACH_BIT_WIDTH` have # both 32-bit and 64-bit outputs updated by the PR author, before # the PR is approved and tested for merging. # It will also detect tests lacking `// EMIT_MIR_FOR_EACH_BIT_WIDTH`, # despite having different output on 32-bit vs 64-bit targets. ../x.py --stage 1 test tests/mir-opt  --host='' --target=i686-unknown-linux-gnu </del> <ins> ../x.py --stage 1 test --skip src/tools/tidy &&  # Run the `mir-opt` tests again but this time for a 32-bit target. # This enforces that tests using `// EMIT_MIR_FOR_EACH_BIT_WIDTH` have # both 32-bit and 64-bit outputs updated by the PR author, before # the PR is approved and tested for merging. # It will also detect tests lacking `// EMIT_MIR_FOR_EACH_BIT_WIDTH`, # despite having different output on 32-bit vs 64-bit targets. ../x.py --stage 1 test tests/mir-opt  --host='' --target=i686-unknown-linux-gnu &&  # Run `ui-fulldeps` in `--stage=1`, which actually uses the stage0 # compiler, and is sensitive to the addition of new flags. ../x.py --stage 1 test tests/ui-fulldeps </ins> fi # NOTE: intentionally uses all of `x.py`, `x`, and `x.ps1` to make sure they all work on Linux.

Discussion:
When I run locally, I get errors: (Same for 27 ui-fulldeps tests in total.) I assume this happened after cc
Since CI isn't running into these issues, I'm guessing it only happens with and works fine with .
Yup, it works fine with here.
Ugh, this keeps happening to when we add new flags.
I think we should just test in CI to make sure this doesn't keep happening. See the description of to understand why ui-fulldeps actually builds with stage0, which means that modifications to the UI test code adding new flags need to make sure they're properly gating their code.
Either that, or we need something like and pass that just to the ui-fulldeps suite on stage1. That seems more like a hack though :s
should be pretty easy to extend with a --stage=1 for ui-fulldeps.
Cool, will do when I get home.
Change:
/// Returns `true` as long as there are more things to do. /// /// This is used by [priroda](https://github.com/oli-obk/priroda) <ins> /// /// This is marked `#inline(always)` to work around adverserial codegen when `opt-level = 3` #[inline(always)] </ins> pub fn step(&mut self) -> InterpResult<'tcx, bool> { if self.stack.is_empty() { return Ok(false);

Discussion:
Stack trace: Examples:
In we build with LLVM assertions enabled, but there is no messages from the log, meaning the segfault is not caused by broken assertions.
When setting opt-level=3 I believe that also changes the C/C++ code's optimization level, so this may be a but in clang's O3 optimization passes as well (and may in theory be fixable by compiling C++ code with O2)
I inspected generated CMake files and LLVM is built with nowadays but Rust is still using . How can I see if reapplying works without possibly breaking CI?
mentions LLVM7.0. Rust recently . So is this still an issue?
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. // Check that we check fns appearing in constant declarations. // Issue #22382. // How about mutating an immutable vector? const MUTATE: fn(&Vec<String>) = { fn broken(x: &Vec<String>) { x.push(format!("this is broken")); //~^ ERROR cannot borrow } broken }; fn main() { } </ins>

Discussion:
Functions defined inside of declarations seem to ignore all lifetimes and mutability. This allows for massively violating the safety guarantees of Rust:
Nominating, this seems incredibly serious.
According to it seems that the borrowck isn't bothering to walk statics/consts (see ). Presumably this code was never updated when it became possible to use blocks as the initializer expression.
Um, yeah, not good. I'll investigate soonish, presuming doesn't get there first.
P-back-compatlang, 1.0 beta
Change:
let result = loop { match *scope { Scope::Body { id, s } => { <ins> // Non-static lifetimes are prohibited in anonymous constants under // `min_const_generics`. self.maybe_emit_forbidden_non_static_lifetime_error(id, lifetime_ref); </ins> outermost_body = Some(id); scope = s; }

Discussion:
Nightly on playground <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
we should forbid lifetimes in anonymous constants to avoid this issue.

results in
Could this be a duplicate of ?
:+1: This probably has the same fix. I do think that the issues are different enough to keep this one open though
Change:
| |__________^ required by this bound in `is_maybe_transmutable` error[E0277]: `u128` cannot be safely transmuted into `DistantVoid` <del> --> $DIR/uninhabited.rs:70:43 </del> <ins> --> $DIR/uninhabited.rs:92:43 </ins> | LL |     assert::is_maybe_transmutable::<u128, DistantVoid>(); |                                           ^^^^^^^^^^^ at least one value of `u128` isn't a bit-valid value of `DistantVoid`

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' 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: [evaluateobligation] evaluating trait selection obligation [typeck] type-checking -- label +F-transmutability <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
Ah, it's an uninhabited non-ZST!
claim
I guess that answers my ;)
Change:
///   * `call_once` was called, but has not yet completed, ///   * the `Once` instance is poisoned /// <del> /// It is also possible that immediately after `is_completed` /// returns false, some other thread finishes executing /// `call_once`. </del> <ins> /// This function returning `false` does not mean that `Once` has not been /// executed. For example, it may have been executed in the time between /// when `is_completed` starts executing and when it returns, in which case /// the `false` return value would be stale (but still permissible). </ins> /// /// # Examples /// /// ``` <del> /// #![feature(once_is_completed)] </del> /// use std::sync::Once; /// /// static INIT: Once = Once::new();

Discussion:
Implemented in
The documentation needs to be made slightly more strict. For example: Should be replaced with The distinction is important, because at the exact moment this function returns might already be executed/resolved, without it necessarily happening “immediately after”. To avoid people shotgunning their feet off, I would suggest to add some guidance on how this should be used. For example, doing something useful based on this function returning a is somewhat likely to be a bug. And yet, examples do not really result in such an impression.
CC for nagisa’s comment above.
It's been 9 months since this was implemented. Can this be stabilized now?
Is there anything preventing this method from being stabilized? It looks like there was some bikesheding in but it's now been just past a year since initial adoption.
Note that I am personally no longer directly interested in having this method: in , I ended-up copy-pasting the whole of anyway. That said, this does look like straightforward addition, which allows to do more with the thing, without actually expanding it's surface area greatly.
Change:
<ins> error: constant evaluation is taking a long time --> $SRC_DIR/core/src/num/mod.rs:LL:COL | = 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/timeout.rs:8:1 | LL | static ROOK_ATTACKS_TABLE: () = { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = note: `#[deny(long_running_const_eval)]` on by default = note: this error originates in the macro `uint_impl` (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error </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. --Minimum example: I have a full project where I was able to consistently cause this error. It seems to be related to the timeout on constant evaluation. For my project which consistently has the error, check . For some reason, annotating with prevents this error. <!-- 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
cc
I just checked - I was able to cause this error to occur in 1.72 nightly but not in 1.70 stable.
Change:
ExprKind::Repeat(ref elem, ref ct) => { self.visit_expr(elem); self.with_lifetime_rib(LifetimeRibKind::AnonConst, |this| { <del> this.with_lifetime_rib(LifetimeRibKind::Elided(LifetimeRes::Static), |this| { </del> <ins> this.with_lifetime_rib(LifetimeRibKind::Elided(LifetimeRes::Infer), |this| { </ins> this.resolve_anon_const(ct, IsRepeatExpr::Yes) }) });

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: I expected to see this happen: It compile Instead, this happened: It errored <!-- 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. --: </p</details
this is also present with repeat exprs:
cc and
const generic defaults also are buggy around
Change:
// Record to group diagnostics. let hir_id = tcx.hir().local_def_id_to_hir_id(def_id); let level = tcx.lint_level_at_node(lint::builtin::DEAD_CODE, hir_id).0; <del> dead_variants.push(DeadVariant { def_id, name: variant.name, level }); </del> <ins> dead_variants.push(DeadItem { def_id, name: variant.name, level }); </ins> continue; }

Discussion:
At some point between (works) and (does not work) the following stopped compiling: I have not bisected for the exact commit that broke this. I have only tried to reproduce this error using . It's possible that this is also broken for other lints. PR:
Without properly double-checking this, I'm certain that this regressed in (merged April 14) which condensed multiple diagnostics triggered by methods into a single one for readability meddling with the affairs of . I don't know how is implemented but if it only considers the first primary span of a (buffered) lint diagnostic, then one fix will be changing the relevant part of the code to consider all primary spans. label T-compiler A-lint F-lintreasons
Change:
("X",   10), ("IX",   9), ("V",   5), ("IV",   4), ("I",    1)]; <del> let text = match args { [TokenTree::Token(_, token::Ident(s, _))] => s.to_string(), </del> <ins> if args.len() != 1 { cx.span_err( sp, &format!("argument should be a single identifier, but got {} arguments", args.len())); return DummyResult::any(sp); } let text = match args[0] { TokenTree::Token(_, token::Ident(s, _)) => s.to_string(), </ins> _ => { cx.span_err(sp, "argument should be a single identifier"); return DummyResult::any(sp);

Discussion:
The first example
Thanks, these are hard to keep in sync, as they don't get automated testing :/
Change:
{ "type": "test", "name": "c", "event": "ok" } { "type": "test", "event": "started", "name": "d" } { "type": "test", "name": "d", "event": "ignored" } <del> { "type": "suite", "event": "failed", "passed": 2, "failed": 1, "allowed_fail": 0, "ignored": 1, "measured": 0, "filtered_out": "0" } </del> <ins> { "type": "suite", "event": "failed", "passed": 2, "failed": 1, "allowed_fail": 0, "ignored": 1, "measured": 0, "filtered_out": 0 } </ins>

Discussion:
The output of a test suite starting when using the json formatter represents "test_count" as a json string, like so: I would expect it to be a number like this:
It also seems like "filtered_out" on run finish is also unexectedly a string.
Change:
<del> Subproject commit 3bd7215d48ba05f18401cc340ae8d71af002ba6d </del> <ins> Subproject commit fd1df1554a22accde727e8c4bdeb2a065627d10c </ins>

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool rls 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!
The error:
See , the way to do this now is to set .
Oh oops, you already opened