jiebi/CodeConvo huggingface dataset:
Change:
The working example in builds fine, but if I add it panics. Repro: It builds fine: Panics with : <details<summaryBacktrace</summary</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think the panic was by you. Could you say a few words on what the issue here? I'd be happy to investigate further and fix, but I have no idea where to start.
That's an oversight by me. In you instead need to do something similar to mir printing. That is, use instead of , but also create a second dump for by additionally using to show the graph of the ctfe version of the const fn
is somewhat related, as we should probably first fix that one and then deduplicate the mir selection logic between cfg printing and regular mir dumps.
has a smaller repro.
claim

Discussion:
use rustc_graphviz as dot; use rustc_hir::def_id::DefId; use rustc_middle::mir::*; <del> use rustc_middle::ty::TyCtxt; </del> <ins> use rustc_middle::ty::{self, TyCtxt}; </ins> use std::fmt::Debug; use std::io::{self, Write};

{ let def_ids = dump_mir_def_ids(tcx, single); <del> let use_subgraphs = def_ids.len() > 1; </del> <ins> let mirs = def_ids .iter() .flat_map(|def_id| { if tcx.is_const_fn_raw(*def_id) { vec![tcx.optimized_mir(*def_id), tcx.mir_for_ctfe(*def_id)] } else { vec![tcx.instance_mir(ty::InstanceDef::Item(ty::WithOptConstParam::unknown( *def_id, )))] } }) .collect::<Vec<_>>(); let use_subgraphs = mirs.len() > 1; </ins> if use_subgraphs { writeln!(w, "digraph __crate__ {{")?; } <del> for def_id in def_ids { let body = &tcx.optimized_mir(def_id); write_mir_fn_graphviz(tcx, body, use_subgraphs, w)?; </del> <ins> for mir in mirs { write_mir_fn_graphviz(tcx, mir, use_subgraphs, w)?; </ins> } if use_subgraphs {

<ins> // check-pass // dont-check-compiler-stdout // compile-flags: -Z unpretty=mir-cfg // This checks that unpretty=mir-cfg does not panic. See #81918. const TAG: &'static str = "ABCD"; fn main() { if TAG == "" {} } </ins>
Change:
I tried this command: I expected to see files installed to Instead, I see files installed to This worked on Rust 1.49, and I noticed the change in testing the Rust 1.50 pre-release. I'm going ahead to call this stable-to-stable since 1.50 is imminent. modify labels: +regression-from-stable-to-stable -regression-untriaged The specific change appears to be commit from , a backport of from , where the default install changed from "share/doc/rust" to just "share/doc". cc Also note that still documents that the default is "share/doc/rust".
labeling to as per sibling PR

Discussion:
let prefix = default_path(&builder.config.prefix, "/usr/local"); let sysconfdir = prefix.join(default_path(&builder.config.sysconfdir, "/etc")); let datadir = prefix.join(default_path(&builder.config.datadir, "share")); <del> let docdir = prefix.join(default_path(&builder.config.docdir, "share/doc")); </del> <ins> let docdir = prefix.join(default_path(&builder.config.docdir, "share/doc/rust")); </ins> let mandir = prefix.join(default_path(&builder.config.mandir, "share/man")); let libdir = prefix.join(default_path(&builder.config.libdir, "lib")); let bindir = prefix.join(&builder.config.bindir); // Default in config.rs
Change:
I attempted to compile a crate containing the following expression: I expected it to compile successfully. Instead, I received this error: : omitted, it did not produce anything else. diagnosed the cause and offered a solution .
While I try to spin up a rustc development environment, can someone point me to the tests for this code? I don't see any tests in the crate.
I think I have a working development environment now. I'll try to fix this -- thank you for making this easy for me!

Discussion:
} else if reg == InlineAsmReg::AArch64(AArch64InlineAsmReg::x30) { // LLVM doesn't recognize x30 "{lr}".to_string() <ins> } else if reg == InlineAsmReg::Arm(ArmInlineAsmReg::r14) { // LLVM doesn't recognize r14 "{lr}".to_string() </ins> } else { format!("{{{}}}", reg.name()) }

asm!("adr r0, {}", sym extern_static); } <ins> // Regression test for #82052. // CHECK-LABEL: issue_82052 // CHECK: push {{.*}}lr // CHECK: @APP // CHECK: @NO_APP pub unsafe fn issue_82052() { asm!("", out("r14") _); } </ins> macro_rules! check { ($func:ident $ty:ident $class:ident $mov:literal) => { #[no_mangle]
Change:
When compiling the following minimal AVR template in --release mode, the compiler aborts with an LLVM error (This is an empty template with an empty main that does nothing.) In debug mode the build works correctly: <!-- 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’ve got the same problem. I am building my software based upon the AVR template "avr-” which I called "avr-unknown-gnu-”. This file looks mostly identical to the existing atmega’s on the web : I tried to build my project (which is just empty) on the nightly and stable versions, but I get the same type of error:
This is caused by A fix is pending in LLVM, but not yet merged... In the meantime, you can use the compiler version:
sorry to reopen this older issue but I'm seeing the same issues. I've tried like 3 different versions of the rust compiler, plus the current (1.55) version, and they all have the exact same issue?
is the last working version as of now. We're still blocked on a fix landing in LLVM which is pending review (see the compiler-builtins issue linked above).
Is there any plan to resolve this issue?
They are working on fixing the underlying bug in LLVM -
Thanks for the update,
Thanks for fixing this bug! :)

Discussion:
<del> Subproject commit fc10370ef7d91babf512c10505f8f2176bc8519d </del> <ins> Subproject commit 593484fc1596707406b0b0b45b97feb08d2a1bfc </ins>
Change:
<!-- 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. --I tried to call default trait implementation from overriden method. Googling was not so useful as wanted so I started playing with "super" keyword and found this bug. Bug appears both on stable and nightly <!-- 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 --
Bisected:
Relevant code: In case it helps, the merges in nightly-2020-06-05 were , , , , , and . Playground:
Error from just before the regression was introduced (run with ):
Assigning and removing as ) in the prioritization working group.
claim

Discussion:
crate_lint: CrateLint, ) -> PartialRes { tracing::debug!( <del> "smart_resolve_path_fragment(id={:?},qself={:?},path={:?}", </del> <ins> "smart_resolve_path_fragment(id={:?}, qself={:?}, path={:?})", </ins> id, qself, path

// Before we start looking for candidates, we have to get our hands // on the type user is trying to perform invocation on; basically: <del> // we're transforming `HashMap::new` into just `HashMap` let path = if let Some((_, path)) = path.split_last() { path } else { return Some(parent_err); </del> <ins> // we're transforming `HashMap::new` into just `HashMap`. let path = match path.split_last() { Some((_, path)) if !path.is_empty() => path, _ => return Some(parent_err), </ins> }; let (mut err, candidates) =

<ins> fn main() { super(); //~ ERROR failed to resolve: there are too many leading `super` keywords } </ins>

<ins> error[E0433]: failed to resolve: there are too many leading `super` keywords --> $DIR/issue-82156.rs:2:5 | LL |     super(); |     ^^^^^ there are too many leading `super` keywords error: aborting due to previous error For more information about this error, try `rustc --explain E0433`. </ins>
Change:
I tried this code: : Note: A simpler program does not crash, but does not compile.
Is it possible for you to share the code?
It might be better for you to share the code which reproduces the issue on your nightly, 2021-02-11, so that I can try to reproduce it on the latest nightly build and possibly find the commit that might have introduced this issue.
Okay, I'll trim down my base and share it later today.
I deleted my whole project and got this
Thanks label: -E-needs-mcve
Not sure if this helps: I ran on my host target , and it is shown that it ICEd back in 2018 (even before the initial implementation of the feature.
Duplicate of

Discussion:
) -> hir::ExprKind<'hir> { macro_rules! make_if { ($opt:expr) => {{ <ins> let cond = self.lower_expr(cond); </ins> let then_expr = self.lower_block_expr(then); <del> hir::ExprKind::If(self.lower_expr(cond), self.arena.alloc(then_expr), $opt) </del> <ins> hir::ExprKind::If(cond, self.arena.alloc(then_expr), $opt) </ins> }}; } if let Some(rslt) = else_opt {

<ins> #![feature(let_chains)] //~ WARN the feature `let_chains` is incomplete fn main() { if true && let x = 1 { //~ ERROR `let` expressions are not supported here let _ = x; } } </ins>

<ins> error: `let` expressions are not supported here --> $DIR/issue-82290.rs:4:16 | LL |     if true && let x = 1 { |                ^^^^^^^^^ | = note: only supported directly in conditions of `if`- and `while`-expressions = note: as well as when nested within `&&` and parenthesis in those conditions warning: the feature `let_chains` is incomplete and may not be safe to use and/or cause compiler crashes --> $DIR/issue-82290.rs:1:12 | LL | #![feature(let_chains)] |            ^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default = note: see issue #53667 <https://github.com/rust-lang/rust/issues/53667> for more information error: aborting due to previous error; 1 warning emitted </ins>
Change:
There is too little confidence in this mistake, why not return to errno. The mmap interface provides the errno, such as the ENOMEM and SIGSEGV interfaces. panic!("failed to allocate an alternative stack")
!
Please try again your code latest nightly Rust version. Also could you paste the ICE backtrace? label E-needs-mcve I-ICE
This is not a ICE This issue propose printing errno on this :
Probably we want this then: label: -I-ICE, -T-compiler, +T-libs

Discussion:
))] mod imp { use super::Handler; <ins> use crate::io; </ins> use crate::mem; use crate::ptr;

0, ); if stackp == MAP_FAILED { <del> panic!("failed to allocate an alternative stack"); </del> <ins> panic!("failed to allocate an alternative stack: {}", io::Error::last_os_error()); </ins> } let guard_result = libc::mprotect(stackp, page_size(), PROT_NONE); if guard_result != 0 { <del> panic!("failed to set up alternative stack guard page"); </del> <ins> panic!("failed to set up alternative stack guard page: {}", io::Error::last_os_error()); </ins> } stackp.add(page_size()) }

use libc::{mmap, mprotect}; use libc::{MAP_ANON, MAP_FAILED, MAP_FIXED, MAP_PRIVATE, PROT_NONE, PROT_READ, PROT_WRITE}; <ins> use crate::io; </ins> use crate::ops::Range; use crate::sync::atomic::{AtomicUsize, Ordering}; use crate::sys::os;

0, ); if result != stackaddr || result == MAP_FAILED { <del> panic!("failed to allocate a guard page"); </del> <ins> panic!("failed to allocate a guard page: {}", io::Error::last_os_error()); </ins> } let result = mprotect(stackaddr, page_size, PROT_NONE); if result != 0 { <del> panic!("failed to protect the guard page"); </del> <ins> panic!("failed to protect the guard page: {}", io::Error::last_os_error()); </ins> } let guardaddr = stackaddr as usize;
Change:
jemalloc is supposed to be enabled on macos for rustc, but with all the testing I've done, it does not appear to work. Noted by Thom Chiovoloni on Zulip , the jemalloc-sys crate prevents using unprefixed symbols , which IIUC, means that it is building with symbols like , which AFAIK are never actually used. If it indeed does not work, then I think it would be good to consider either looking into fixing it (which I suspect may not be easy), or stop building it on CI. Tested with most recent nightly () and master ().
You can't override the macos malloc by shadowing its symbols (I think very early allocations in the loader still use the original malloc or something?). Instead, jemalloc actually hooks directly into some macos allocator APIs to replace the guts behind the original symbols IIRC.
This is where the magic happens I believe:
Thanks for taking a look! Do you happen to know if there's some way to validate that it is working? When I run with the environment variable I get that rustc has allocated bytes regardless of how big of a crate I build. Is there maybe a better way to determine if it is actually working?
Ah - when statically linking to jemalloc, the zone_register constructor function appears to be dropped by the linker: The compiler already manually marks other bits of jemalloc as : Extending that with Gets it registered properly for me with a little test crate.
Ah, I can confirm with those changes it seems to be working. I might do some benchmarking to see how it does, but pending , it may not be necessary.
I ran a few benchmarks, and it looks promising: (Not sure why the prebuilt nightly is so much slower. Maybe some random setting like MACOSXDEPLOYMENTTARGET?) These are pretty typical numbers of the various projects I tried. I also tested tikv-jemalloc-sys, but I didn't see much difference from the current jemalloc.
Pretty neat! would need macOS support too, so this should give clues on how to add it.
You should make sure this works on macOS pre-10.12, as this version changed how a number of things work (without looking at jemalloc, possibly most relevant being interpose)

Discussion:
static _F5: unsafe extern "C" fn(*mut c_void, usize) -> *mut c_void = jemalloc_sys::realloc; #[used] static _F6: unsafe extern "C" fn(*mut c_void) = jemalloc_sys::free; <ins> // On OSX, jemalloc doesn't directly override malloc/free, but instead // registers itself with the allocator's zone APIs in a ctor. However, // the linker doesn't seem to consider ctors as "used" when statically // linking, so we need to explicitly depend on the function. #[cfg(target_os = "macos")] { extern "C" { fn _rjem_je_zone_register(); } #[used] static _F7: unsafe extern "C" fn() = _rjem_je_zone_register; } </ins> } rustc_driver::set_sigpipe_handler();
Change:
The following code: produces the following error: is a , so writing would produce a . This is very unlikely to be what the user wants - and in this case, it won't even work, since there are no impls for . Tested on <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This problem occurs not only when 's type is , but also i32 and other types. This help message will be emitted if could coerce to . But I think this is weird. This coercion should be based on , and to coerce, we need implementation of for 's type. In other words, it seems that all types have implementation of . This behavior should be incorrect also from . I'm going to check why the compiler provides above implementation.
This suggestion uses to determine whether to emit the message. And then calls . execute trait selection. Even if a type needs implementation, trait selection does not check , . However, also . As a result, does not check whether 's type has implementation of . But, I have no idea how to fix this. I'll leave this issue.

Discussion:
<ins> // https://github.com/rust-lang/rust/issues/82446 // Spurious 'help: store this in the heap' regression test trait MyTrait {} struct Foo { val: Box<dyn MyTrait> } fn make_it(val: &Box<dyn MyTrait>) { Foo { val //~ ERROR [E0308] }; } fn main() {} </ins>

<ins> error[E0308]: mismatched types --> $DIR/issue-82446.rs:11:9 | LL |         val |         ^^^ expected struct `Box`, found reference | = note: expected struct `Box<(dyn MyTrait + 'static)>` found reference `&Box<(dyn MyTrait + 'static)>` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>
Change:
As can be seen when going to , the "List of all items" page generated by rustdoc has a header saying "List of all items List of all items": ! <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Mentoring instructions: remove this line:
I think this regressed in cc do you have time to take a look?
How did that happen... Whoops, I'll fix asap As an aside, that bug should've been "List of List of all items" for a bit of wikipedia-plagiarism. claim

Discussion:
</a> </span> </span> <del> <span class="in-band">List of all items</span> </del> </h1>", ); // Note: print_entries does not escape the title, because we know the current set of titles

sorted.sort_by(|&l, r| compare_names(l, r)); assert_eq!(names, sorted); } <ins> #[test] fn test_all_types_prints_header_once() { // Regression test for #82477 let all_types = AllTypes::new(); let mut buffer = Buffer::new(); all_types.print(&mut buffer); assert_eq!(1, buffer.into_inner().matches("List of all items").count()); } </ins>
Change:
While linting my code I came across  which was triggered in my code. This suggests the change from: Into: Both are valid code with same result. But the does not state that this is expected behavior. Yes, this is stated . But this was not strait forward (in my opinion) to find. It took me writing a whole bug report and looking a bunch of thing up to figure this out. (and I'm not even new to Rust anymore) I would suggest adding some example code to make his explicit. Here is a suggestion: (after the section) This makes both this behavior cleared, easier to find and exposes people to code like this so they are less surprised if clippy starts warning them. It looks like this behavior might be more common in the future too. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label T-doc T-libs.
I'm not sure I like clippy's suggestion, personally, but I think your suggested documentation is reasonable. I would also point out that mapping to / followed by (or a similar ) is better written as (with for ).
I was also confused when I saw the suggestion. But once I realizing what is was doing it sounded in line with things like . That does not mean that I like it, but at least people know it is intended that way and not a side-effect.
I encountered the same clippy warning when iterating over Results, and got perplexed. With the current state of documentation, I personally perceive the warning as suggestion to write obfuscated code hiding the fact that error checking is missing. Adding the documentation change suggested by would make it much easier to realize what flatten() does. Maybe it might be made even more clear how it works if phrasing the first line something like this: Me too am no longer new to Rust, and thought I had a proficient understanding of flatten() after having used it to unroll nested arrays. Likely I'll not be the last person to be surprised it can also be used to discard Err values.
claim

Discussion:
/// assert_eq!(merged, "alphabetagamma"); /// ``` /// <ins> /// Flattening works on any `IntoIterator` type, including `Option` and `Result`: /// /// ``` /// let options = vec![Some(123), Some(321), None, Some(231)]; /// let flattened_options: Vec<_> = options.into_iter().flatten().collect(); /// assert_eq!(flattened_options, vec![123, 321, 231]); /// /// let results = vec![Ok(123), Ok(321), Err(456), Ok(231)]; /// let flattened_results: Vec<_> = results.into_iter().flatten().collect(); /// assert_eq!(flattened_results, vec![123, 321, 231]); /// ``` /// </ins> /// Flattening only removes one level of nesting at a time: /// /// ```
Change:
<!-- 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</detailsThe bug happens in here: It happens due to an assertion that the error is a which it isn't i guess. I think it's related to a type being contained within itself, but not really.
This ICEs since 1.49.0. In 1.48.0, gives the following errors:
bisection result searched nightlies: from nightly-2020-08-01 to nightly-2021-03-10 regressed nightly: nightly-2020-10-07 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning as discussed as part of the and removing . label -I-prioritize +P-medium
Slightly simplified:
No longer ICEs since

Discussion:
<ins> trait A<Y, N> { type B; } type MaybeBox<T> = <T as A<T, Box<T>>>::B; struct P { t: MaybeBox<P>, //~ ERROR: overflow evaluating the requirement `P: Sized` } impl<Y, N> A<Y, N> for P { type B = N; } fn main() { let t: MaybeBox<P>; } </ins>

<ins> error[E0275]: overflow evaluating the requirement `P: Sized` --> $DIR/issue-82830.rs:7:8 | LL |     t: MaybeBox<P>, |        ^^^^^^^^^^^ | note: required because of the requirements on the impl of `A<P, Box<P>>` for `P` --> $DIR/issue-82830.rs:10:12 | LL | impl<Y, N> A<Y, N> for P { |            ^^^^^^^     ^ error: aborting due to previous error For more information about this error, try `rustc --explain E0275`. </ins>
Change:
I tried this code (thanks to for the minified version): I expected the code to print , the length of the slice. Instead, a random value is printed. It most recently worked on: : : <!-- Did the compiler crash? If so, please provide a backtrace. -- modify labels: +regression-from-nightly-to-nightly -regression-untriaged
Are you able to share a code snippet that reproduces your bug, even a long example is fine for now?
Very likely caused by LLVM upgrade.
I'm having lunch now, but I'll see what I can do afterwards :)
So far, my only progress is that works whilst the following does not: Again, adding a inside the loop makes the second example work. I'm still trying to reduce this problem to an example which can be reproduced without including code from my project.
Ok, I finally was able to reduce this bug to its bones - here is the code (it turned out to be quite different than what I had originally expected): You can see that on the current nightly, this snippet prints a random value: It should, as demonstrated on the release branch, print , the length of the slice : My best guess is that in debug mode (this bug does not occur in release), we are actually trying to read the length of our slice . However, some change to codegen may have optimised out storing that length, so that we are reading garbage from the stack.
Slightly smaller:
Hmm, this also happens in debug mode for me (both with the larger and smaller example).
It doesn't work in release mode. It only works in debug mode
This requires : -
This is likely the same issue as .
Assigning and removing .

Discussion:
<del> Subproject commit 5f958e150d377e608d2f1f208b86110218d5da3c </del> <ins> Subproject commit 62a1ddde22c267249eda72184520a21ad2052f0b </ins>

<ins> // run-pass // compile-flags: -Ccodegen-units=1 -Cinline-threshold=0 -Clink-dead-code -Copt-level=0 -Cdebuginfo=2 // ignore-tidy-linelength // Make sure LLVM does not miscompile this. fn make_string(ch: char) -> String { let mut bytes = [0u8; 4]; ch.encode_utf8(&mut bytes).into() } fn main() { let ch = '😃'; dbg!(ch); let string = make_string(ch); dbg!(string); } </ins>

<ins> // run-pass // compile-flags: -Copt-level=0 -Cdebuginfo=2 // Make sure LLVM does not miscompile this. fn indirect_get_slice() -> &'static [usize] { &[] } #[inline(always)] fn get_slice() -> &'static [usize] { let ret = indirect_get_slice(); ret } fn main() { let output = get_slice().len(); assert_eq!(output, 0); } </ins>