jiebi/CodeConvo huggingface dataset:
Change:
// lldb-command:continue <ins> #![feature(asm)] </ins> #![feature(naked_functions)] #![feature(omit_gdb_pretty_printer_section)] #![omit_gdb_pretty_printer_section]

Discussion:
The test is failing on AArch64's CI:
ping arm
Hey ARM Group! This bug has been identified as a good "ARM candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
Just like with every LLVM update it might fix itself or get worse after
The test is causing an infinite loop due to the link register being updated during the call to zzz, that call is causing the link register to be the ret instruction after that call, the ret instruction then returns to the link register causing an infinite loop. Normally before the call the link register would be saved and then restored after the call, however due to this being a naked function that isn't happening. The emitted LLVM IR is just calling the function and that call isn't preserving anything so this could change in a future version of LLVM I suppose. Although with c++ and clang that code would fail to compile as you can only use asm inside a naked function. suggests it's a bug in rustc for allowing the code to compile, is that still your understanding? I also suspect it's why this was raised. I can get the test to pass, but I'm wondering if the test is actually correct in it's current state. EDIT: It's probably worth pointing out that the code in that test will segfault on x86_64
The test is definitely incorrect. Using anything other than inline asm in a naked function is UB.
Change:
E0164, E0165, E0166, <del> E0167 </del> <ins> E0167, E0168 </ins> )

Discussion:
Not the best title, but I suppose it somehow summarizes the situation. There's no ICE if I un-comment "use buffer" and prefix Buffer as the comment is suggesting. There's also no ICE if I rename Buffer into anything else. (fun!) rustc 0.13.0-nightly ( 2014-11-11 22:37:05 +0000) binary: rustc commit-hash: commit-date: 2014-11-11 22:37:05 +0000 host: x8664-apple-darwin release: 0.13.0-nightly
Change:
<ins> //! This test checks that external macros don't hide //! the const eval timeout lint and then subsequently //! ICE. // compile-flags: --crate-type=lib -Ztiny-const-eval-limit // error-pattern: constant evaluation is taking a long time static ROOK_ATTACKS_TABLE: () = { 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); 0_u64.count_ones(); }; </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:
err.span_help(where_constraints, where_msg); } } err.emit(); } }

Discussion:
Given the following code: The current output is: is wrong, specifying another isn't going to fix the problem. Writing just has a suggestion where`, which is good, but the concrete syntax would be nice. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We probably should modify E0191 to hint that an supertrait's associated type is shadowed. I think E0719 here is fine to keep as-is, imo.
I agree the message for E0719 is good as-is.
Is this issue fixed ? If not can I take this up, please. Also how exactly should E0191 be modified. Imo, I don't think E0191 should pop up in this case as E0719 conveys the message.
claim
claim
Ask for help How do I specify the association type of supertrait with the same name? In other words, is there an easy way to modify the code in the issue to make it pass compilation? Here's my clumsy way of creating a new trait.
Is this issue still open? If so I would like to take a crack at it.
If you can still reproduce it, then yes indeed. assign
Error: Parsing assign command in failed: ...'zyDutchman' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I have now a hint about the shadowing: But I am not quite sure about what to do about the actual message. Do we want to suggest renaming to something else Or do we want to suggest the work-around by
If the trait is local, then we could suggest renaming it. It's not required to be super specific here--we could just note the conflict to make the user aware of it, for example.
I have updated the help message so that this case: gives this error message: The rename help message is emitted for both the super trait and the subtrait, if they are local. I think I am ready to make a merge request, or does somebody have something else to add?
I recommend you to just open a PR. Any further discussions can happen over there :)
Change:
unsafe { cmath::cbrtf(self) } } <del> /// Calculates the length of the hypotenuse of a right-angle triangle given /// legs of length `x` and `y`. </del> <ins> /// Compute the distance between the origin and a point (`x`, `y`) on the /// Euclidean plane. Equivalently, compute the length of the hypotenuse of a /// right-angle triangle with other sides having length `x.abs()` and /// `y.abs()`. </ins> /// /// # Examples ///

Discussion:
The documentation for the / function reads and gives this example (and the analogous example for ): Since lengths are always positive, it's unclear what this function does for negative values. My expectation is that it gives the hypotenuse of the right triangle whose leg lengths are the absolute values of and , but I had to look up to be sure, which reads <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This looks relatively simple, and I'd like to contribute. Could I take this issue?
claim
Change:
} fn describe_debug_flags() { <del> println!("nAvailable debug options:n"); </del> <ins> println!("nAvailable options:n"); </ins> print_flag_list("-Z", config::DB_OPTIONS); }

Discussion:
Right now, The Unstable Book is just a list of unstable lang/lib features. There are other things like compiler flags which are also considered unstable that should be documented in The Unstable Book. This requires adjusting a bit to accommodate other sections. Right now I'm thinking that all sections (features, flags, etc) will live in their own subdirectory.
Relevant thread:
Reminder for future self: remove this hack
This may not be the issue, but there are a number of stable features that are actually just "stable", like target specs and llvm plugins, where we don't even try to maintain stability. It would be nice to have a discussion of those somewhere.
I'm waiting on to merge before I work on this.
Copying text from
This was partially completed in
In suggests that we should keep the library features minimal; I agree. They should exist, so you can see everything that's unstable, but there's no reason to duplicate their docs.
regarding unsafe command line options, one can see them via . it looks like the options are all defined . they seem to all be exposed on . seems like we should be able to autogenerate all the unsafe command line options pages like we do for the other unstable book sections (via )
Triage: we now have , but it doesn't talk about .
I just saw that the Unstable Book already contains a list of unstable compiler flags which I guess means that this issue is already solved right? Maybe we should create a separate issue for the missing -Z description in and close this one? Maybe also create a separate issue to autogenerate the unsafe nightly commands for the Unstable Book. That way we can keep the tasks that need to be done clearly isolated. If you agree I can create these new issues with a nice description of what needs to be done!
Yes! Alternatively, if this is something you'd like to send a PR for, we can just keep this issue open and use that PR to close it. I would prefer not to, I don't think this is the job for the unstable book.
I'll go ahead and do that then! I can understand that you have this view!

I do not really have much of a view myself on this, though I do think that we should keep duplication between the docs and other docs to a minimum (or to keep documentation duplication to a minimum in general because its easier to maintain). The docs are probably a better place to document this. However, this does lead me to the following question: Currently, there is already a in the unstable book. For example the flag. I think we should either try to complete this section or remove/move it to the docs all-together. What is your opinion on this?
Moving it to the docs seems appropriate to me!
I created an issue for this here: Then we can use this issue for adding -Z to the compiler flags section!
Change:
"{}({}) overruled by outer forbid({})", level.as_str(), lint_name, lint_name); <ins> diag_builder.span_label(span, &format!("overruled by previous forbid")); </ins> match now_source { LintSource::Default => &mut diag_builder, LintSource::Node(forbid_source_span) => { <del> diag_builder.span_note(forbid_source_span, "`forbid` lint level set here") </del> <ins> diag_builder.span_label(forbid_source_span, &format!("`forbid` level set here")) </ins> }, LintSource::CommandLine => { diag_builder.note("`forbid` lint level was set on command line")

Discussion:
From: src/test/compile- E0453 needs a spanlabel and a spannote changed to a span_label, updating it from: To:
Change:
.skip(if is_method { 1 } else { 0 }) .collect(); <del> Some(generic_params.into_iter().zip_eq(params).collect()) </del> <ins> // The surrounding code expects variadic functions to not have a parameter representing // the "..." parameter. This is already true of the FnDecl but not of the body params, so // we drop it if it exists. if fn_decl.c_variadic { params.pop(); } debug_assert_eq!(params.len(), generic_params.len()); Some(generic_params.into_iter().zip(params).collect()) </ins> } }

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at /rust/deps/itertools- 'itertools: .zipeq() reached end of one iterator before the other'', 'thread 'rustc' panicked at /rust/deps/itertools- 'itertools: .zipeq() reached end of one iterator before the other'' 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 -- label +F-cvariadic +F-fndelegation <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
lol
Thanks! I will take a look. (I'm glad we the check!)
another one that does not need delegation I think
claim
Change:
use attr::AttrMetaMethods; use parse::parser::Parser; use parse::token::{str_to_ident}; <ins> use print::pprust::view_item_to_string; </ins> use ptr::P; use util::parser_testing::{string_to_tts, string_to_parser}; use util::parser_testing::{string_to_expr, string_to_item}; <del> use util::parser_testing::string_to_stmt; </del> <ins> use util::parser_testing::{string_to_stmt, string_to_view_item}; </ins> // produce a codemap::span fn sp(a: u32, b: u32) -> Span {

Discussion:
method will unconditionally fail if it encounters a view item ( or ). This is desired behavior if parsing the body of a function. However, there are no public methods that allow parsing either of these items individually. This makes it impossible to parse the full range of possible input to a REPL. If it's acceptable, I could make a pull request for public methods (which already exists, privately) and .
Change:
assert_eq!(size_of::<Option<Option<(bool, &())>>>(), size_of::<(bool, &())>()); assert_eq!(size_of::<Option<Option<(&(), bool)>>>(), size_of::<(bool, &())>()); <ins> assert_eq!(size_of::<Option<Option2<bool, &()>>>(), size_of::<(bool, &())>()); assert_eq!(size_of::<Option<Option2<&(), bool>>>(), size_of::<(bool, &())>()); </ins> }

Discussion:
On x86_64, this prints the values in comments: What's happening here is that when we pick the niche to represent of , we pick the largest (or "roomiest") of the niches in , so that further enums around have more optimization opportunities themselves. (Why just one niche? That has to do with the fact that in an , the only part of the representation guaranteed to be always initialized and valid is the tag / niche, but no other variant fields) For , however, we just pick the best niche in and only look at if has no niches at all, so if has a better niche, we miss it. This is a small oversight in the code itself, and arguably it will be slightly nicer once this is fixed, but I wanted to open this issue first, before I have a chance to fix it myself (if someone else doesn't get there first). cc
I was pretty sure that my patch to find the roomiest niche covered that case, but apparently it didn't. :(
Change:
<ins> // unit-test: GVN #![feature(custom_mir, core_intrinsics)] extern crate core; use core::intrinsics::mir::*; #[custom_mir(dialect = "runtime", phase = "initial")] fn fn0() { // CHECK-LABEL: fn fn0( mir! { let a: usize; let b: [u128; 6]; let c: ([u128; 6],); let d: ([u128; 6],); let x: (); { // CHECK: bb0: { // CHECK-NEXT: _1 = const 1_usize; // CHECK-NEXT: _2 = [const 42_u128; 6]; // CHECK-NEXT: _2[1 of 2] = const 1_u128; // CHECK-NEXT: _3 = (_2,); // CHECK-NEXT: _4 = _3; // CHECK-NEXT: _5 = fn1((_3.0: [u128; 6]), _3) a = 1_usize; b = [42; 6]; b[a] = 1; c = (b,); d = c; Call(x = fn1(Move(c.0), d), ReturnTo(bb1), UnwindUnreachable()) } bb1 = { Return() } } } #[inline(never)] fn fn1(a: [u128; 6], mut b: ([u128; 6],)) { b.0 = [0; 6]; } fn main() { fn0(); } // EMIT_MIR gvn_copy_moves.fn0.GVN.diff </ins>

Discussion:
Right: Wrong: The first argument to is partially moved. GVN causes the second argument to use the partially moved value:
I can't provoke the miscompilation on beta using this example (just had to replace with to make it build), so I don't think there's any need to rush to fix this. (Some part of GVN is used in the beta that's about to become stable, but it looks like it doesn't have this bug in it)
Cc
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
value: &ast::Pat, msg: &str) { if let ast::PatKind::Paren(_) = value.node { <del> let pattern = pprust::pat_to_string(value); Self::remove_outer_parens(cx, value.span, &pattern, msg); </del> <ins> let pattern_text = if let Ok(snippet) = cx.sess().source_map() .span_to_snippet(value.span) { snippet } else { pprust::pat_to_string(value) }; Self::remove_outer_parens(cx, value.span, &pattern_text, msg); </ins> } }

Discussion:
This code snippet () results in the following lint output: The should contain the literal string , not the expanded macro that it repreesnts.
Ah, I think this is because we should be using (to get the code the user actually wrote) (to render the AST); I could PR this tonight.
Change:
<ins> const NUM_RUNS: usize = 10; fn run_self(exe: &str) -> usize { use std::process::Command; let mut set = std::collections::HashSet::new(); let mut cmd = Command::new(exe); cmd.arg("--report"); (0..NUM_RUNS).for_each(|_| { set.insert(cmd.output().expect("failed to execute process").stdout); }); set.len() } fn main() { let mut args = std::env::args(); let arg0 = args.next().unwrap(); match args.next() { Some(s) if s.eq("--report") => { println!("main = {:#?}", &main as *const _); } Some(s) if s.eq("--test-no-aslr") => { let cnt = run_self(&arg0); if cnt != 1 { eprintln!("FAIL: {} most likely ASLR", arg0); std::process::exit(1); } println!("PASS: {} does no ASLR", arg0); } Some(s) if s.eq("--test-aslr") => { let cnt = run_self(&arg0); if cnt != NUM_RUNS { eprintln!("FAIL: {} most likely no ASLR", arg0); std::process::exit(1); } println!("PASS: {} does ASLR", arg0); } Some(_) | None => { println!("Usage: {} --test-no-aslr | --test-aslr", arg0); std::process::exit(1); } } } </ins>

Discussion:
With musl we can generate static binaries just fine. But without much work we can even generate a static position independent executable, which would enable Address Space Layout Randomization for free. For this to work, we need: rustc: gcc: remove any has or replace musl with is a program printing all the AUX vectors, which also contains the entry address of the program. As you can see it changes with every start of the program.
If there will be no native support, at least ship along with and add some possibility to change the startup file.
something like:
The workaround may be similar to what I recently did to statically link to bionic libc () - produce a with and then link manually. ( has nice defaults, but is pretty inflexible when you need to do something different with linking, modulo custom target specifications.)
Hmm, I don't want a workaround. I rather want a secure static binary with ASLR by default.
Change:
<ins> // only-x86_64 // compile-flags: -C target-feature=+sse2,-avx,+avx2 -C target-feature=+avx,-avx2 #![crate_type = "lib"] #[no_mangle] pub fn foo() { // CHECK: attributes #0 = { {{.*}}"target-features"="+sse2,-avx,+avx2,+avx,-avx2"{{.*}} } } </ins>

Discussion:
I'm trying to pass multiple conditionally downstream. However, despite +/- for adding/removing a feature it appears only the last value takes effect.
FWIW, you can check for values without any test program like: $ rustc --print cfg -C target-feature=+avx2 -C target-feature=+fma $ rustc --print cfg -C target-feature=+avx2,+fma
I agree that it's a bug and will try to fix it.
Fixed in
Change:
<ins> error[E0367]: `Drop` impl requires `T: 'static` but the struct it is implemented for does not --> $DIR/relate_lt_in_type_outlives_bound.rs:7:8 | LL |     T: 'static, |        ^^^^^^^ | note: the implementor must specify the same requirement --> $DIR/relate_lt_in_type_outlives_bound.rs:1:1 | LL | / struct Wrapper<'a, T>(&'a T) LL | | where LL | |     T: 'a; | |__________^ error: aborting due to previous error For more information about this error, try `rustc --explain E0367`. </ins>

Discussion:
Looks like it's possible to for a stricter lifetime than the one used in the type: ... which allows to essentially transmute from to , leading to unsoundness: On my machine, it prints:
oops...
Looks like this regressed in 1.56.0.
introduced this
Re-opening to track beta/stable backport.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-critical
(I'm investigating making a more limited version of this PR for backporting to beta/stable.)
we ended up backporting itself to the 1.57 release. So this is now closed.
Change:
<ins> #[repr(transparent)] pub struct PageTableEntry { entry: u64, } #[repr(align(4096))] #[repr(C)] pub struct PageTable { entries: [PageTableEntry; 512], } </ins>

Discussion:
I was writing some code that does some x86 page table configuration, but then I noticed that Rust compiler started to panic with this code: And I did realize that I cannot use in since has attribute. If I rewrite the above code without crate: (Note that this is basically same thing as 's struct) This compiler error is displayed, which is normal: And here's output from (In this case, I'm trying to compile the first code): Looking at the backtrace, there's function and : While there's no line number(since the compiler is installed using ), thankfully there are only two calls to inside . And it seems like the first one is panicking since normal output has nothing more than , but I might be wrong. I ran about five minutes ago before submitting this issue, but result was the same. BTW: I initially found this bug in Clippy, but then I noticed that Rustc was doing the same thing.
Assigning [as discussed as part of the Prioritization WG procedure][link]. [link]: https://rust-(in.20some.20cases).20when.20repr(al
Would you please try this again for us?
The second one is one that does not panic rustc(The code that panics rustc is the first one). It is very similar to the first one except that it does not use external crate, and compiling it shows the error I was expecting. Also, the second code was one of my attempts to reproduce the same panic without external crate, but for some reason, it didn't panic the compiler. Only the first code does.
Change:
use super::ty::{AllowPlus, RecoverQPath, RecoverReturnSign}; use super::{Parser, Restrictions, TokenType}; use crate::errors::PathSingleColon; <ins> use crate::parser::{CommaRecoveryMode, RecoverColon, RecoverComma}; </ins> use crate::{errors, maybe_whole}; use ast::token::IdentIsRaw; use rustc_ast::ptr::P;

Discussion:
Given an invalid call such as: The following diagnostic is issued: This gets much worse on multiline calls: Which just prints out a diagnostic nowhere near the error: Ideally this should mention something about either missing a missing turbofish (e.g. ), or a missing identifier (e.g. ). This would at least get the error pointing to the correct spot. Latest playground nightly (2024-02-09) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Oh, wow, it didn't even occur to me until now that the expression is syntactically valid .< Edit: Wow, even is syntactically well-formed.
This should pretty easy to fix, basically if we fail to parse a type here we should first of all attach a label to the saying something akin to while parsing this list of parenthesized type arguments starting here and we should suggest removing the trailing path separator if the is , the parenthesized generics aren't followed by or and if the list of non-types we encountered can be successfully parsed as a list of expressions (using a snapshot parser). Furthermore, if the is we can try to reparse the list as a list of patterns and provide the same structured suggestion. I will gladly mentor & review any PR for this.
claim
Hello , is this issue still open for mentoring? I can see that already claimed the issue, but there seems to be no progress.
I read the code but no time to finish it at the moment. You can do it.