jiebi/CodeConvo huggingface dataset:
Change:
if let Some(expanded) = maybe_expand_private_type_alias(cx, path) { expanded } else { <del> let path = clean_path(path, cx); </del> <ins> // First we check if it's a private re-export. let path = if let Some(path) = first_non_private(cx, hir_id, &path) { path } else { clean_path(path, cx) }; </ins> resolve_type(cx, path) } }

Discussion:
rustdoc renders renamed imports () using the new, private name (e.g., in ). This is confusing behavior since the new name is an implementation detail. I think it should be using the original item's name instead. As an example, returns a , but the module it's defined in renames to . I would expect rustdoc to still show the item's definition name, but instead it shows the private name.
I don't think this should be changed until is fixed. Otherwise you could have two items shown with the same name and namespace in the same scope.
Code to reproduce: I don't think we need to wait for to be fixed as the fix for this doesn't impact it: if the re-export is not publicly reexported, we simply show the item underneath. When we will it will handle it the same.
Change:
} } <del> let new = ty::ResolvedOpaqueTy { concrete_type: definition_ty, substs: self.tcx().lift_to_global(&opaque_defn.substs).unwrap(), }; let old = self.tables .concrete_existential_types .insert(def_id, new); if let Some(old) = old { if old.concrete_type != definition_ty || old.substs != opaque_defn.substs { span_bug!( span, "visit_opaque_types tried to write  different types for the same existential type: {:?}, {:?}, {:?}, {:?}", def_id, definition_ty, opaque_defn, old, ); </del> <ins> if let Some(substs) = self.tcx().lift_to_global(&opaque_defn.substs) { let new = ty::ResolvedOpaqueTy { concrete_type: definition_ty, substs, }; let old = self.tables .concrete_existential_types .insert(def_id, new); if let Some(old) = old { if old.concrete_type != definition_ty || old.substs != opaque_defn.substs { span_bug!( span, "visit_opaque_types tried to write  different types for the same existential type: {:?}, {:?}, {:?}, {:?}", def_id, definition_ty, opaque_defn, old, ); } </ins> } <ins> } else { self.tcx().sess.delay_span_bug( span, "cannot lift `opaque_defn` substs to global type context", ); </ins> } } }

Discussion:
Another ICE that uses a nightly only feature, but still crashes on stable, beta and nightly without the flag. According to godbolt, this sneaked in with 1.34. 1.33 and lower are not affected. <details<summaryBacktrace:</summary
nevermind I was thinking of , which you also filed
I found this verry related:
Again this is kinda 2 issue's in 1, so I dont know if this should have it's own issue... After some more trying, I found this also panics, but only on nightly: Notice I removed the on the line <details<summaryBacktrace:</summary</details
Another one, stable, beta & nightly: <details<summaryBacktrace:</summary</details
triage: P-high due to ICE; removing nomination.
Likely duplicate from
Change:
self.fatal_proc_rec("compilation failed!", &proc_res); } <ins> if let Some(PassMode::Build) = self.pass_mode() { return; } </ins> let output_path = self.output_base_name().with_extension("ll"); let proc_res = self.verify_with_filecheck(&output_path); if !proc_res.status.success() {

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: code originally from <!-- 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. --: When compile with , there is a which does not occur with `
Due to inlining of :
does the no_mangle attr have done kind of effect? can't check on mobile right now
I think it's more likely the struct's being ignored when performing that field access. cc
A slightly simplified example: It only arises when inlining a generic function (in this case ) that bitcasts a .
The difference seems to be that bitcasts a pointer to a vector, while the inlined bitcasts a vector directly. I suspect that the extra move that happens when is inlined causes vector value to be stored behind a pointer. I can reproduce the crash using just to force an extra move. As for why puts the vector behind a pointer, the default rust abi passes vector types by-ref to ensure that changing target features doesn't change the abi.
With that crashes at and without it gives the following LLVM ir:
It's interesting that the failure (in my example) required to be generic—that shouldn't affect the ABI of the monomorphized function, should it?
Indeed. It shouldn't affect the ABI.
The original no longer crashes since , but still does
Triage: The above mentioned example now compiles fine with the latest nightly, I guess is related. Marking as .
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-82612-return-mutable-reference.rs:18:13 | LL | /         if index < self.values.len() { LL | |             let value = unsafe { self.values.get_unchecked_mut(index) }; LL | |             value.get_or_insert_with(func) | |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `()`, found `&mut V` LL | |         } | |_________- expected this to be `()` | = note:      expected unit type `()` found mutable reference `&mut V` help: consider using a semicolon here | LL |             value.get_or_insert_with(func); |                                           ^ help: consider using a semicolon here | LL |         }; |          ^ help: you might have meant to return this value | LL |             return value.get_or_insert_with(func); |             ^^^^^^                               ^ error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
While writing a SparseArray impl, I forgot a return on . This should_ be an error, but I got an ice instead. This fails with the expected on stable. playground: (Note that switching to stable resolves the ICE) <!-- 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. --:
label regression-from-stable-to-nightly
Bisection result searched nightlies: from nightly-2021-02-22 to nightly-2021-02-28 regressed nightly: nightly-2021-02-24 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
Caused by :
Change:
use marker::Sized; <del> /// A common trait for cloning an object. </del> <ins> /// A common trait for cloning an object. Differs from `Copy` in that you can /// define `Clone` to run arbitrary code, while you are not allowed to override /// the implementation of `Copy` that only does a `memcpy`. </ins> /// <del> /// This trait can be used with `#[derive]`. </del> <ins> /// Since `Clone` is more general than `Copy`, you can automatically make anything /// `Copy` be `Clone` as well. /// /// ## Derivable /// /// This trait can be used with `#[derive]` if all fields are `Clone`. The `derive`d /// implementation of `clone()` calls `clone()` on each field. /// /// ## How can I implement `Clone`? </ins> /// /// Types that are `Copy` should have a trivial implementation of `Clone`. More formally: /// if `T: Copy`, `x: T`, and `y: &T`, then `let x = y.clone();` is equivalent to `let x = *y;`. /// Manual implementations should be careful to uphold this invariant; however, unsafe code /// must not rely on it to ensure memory safety. <ins> /// /// An example is an array holding more than 32 of a type that is `Clone`; the standard library /// only implements `Clone` up until arrays of size 32. In this case, the implementation of /// `Clone` cannot be `derive`d, but can be implemented as: /// /// ``` /// #[derive(Copy)] /// struct Stats { ///    frequencies: [i32; 100], /// } /// /// impl Clone for Stats { ///     fn clone(&self) -> Self { *self } /// } /// ``` </ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait Clone : Sized { /// Returns a copy of the value.

Discussion:
I'm using s as keys in a BtreeMap. I have to look up the map ~15 million times per second (10G ethernet line rate). Ipv4Addr cmp() compiles to this on my system (linux x86-64, rustc 1.10.0-nightly ( 2016-05-21)) Which seems kinda inefficient for a thing which is basically u32. I guess part of the reason is the which converts it to an array(!) first. I copied the definition and implemented Ord like this: It's about 10 times faster on my .
Nice find! Want to send a PR for this? Looks like something that'd be more than welcome :)
Change:
-------- - [Added the `riscv32imc-unknown-none-elf` target.][53822] - [Added the `aarch64-unknown-netbsd` target][53165] <ins> - [Upgraded to LLVM 8.][53611] </ins> Libraries ---------

Discussion:
I'll leave my story here because it shows how important the information can be: We recently upgraded from rustc 1.43 to 1.47 to build Firefox (we got stuck on 1.43 for a large number of complicated reasons, and would still be stuck if we hadn't found workarounds). Anyways, consequently, we've had a bunch of regressions, one of which was performance-related and I was bisecting it. The first thing I did was to compare each rust release, and it turned out the regression started between 1.44 and 1.45. So I went to the 1.45 release notes suspecting LLVM could have been involved and saw nothing there. Now, several hours later bisecting through nightlies (because PGO and LTO being involved, testing one version takes a while), the regression appears to have started between rustc 1.45.0-nightly ( 2020-05-21) and rustc 1.45.0-nightly ( 2020-05-20) So I take my git, type and lo and behold, there it is: I'm still waiting on the results actually confirming LLVM is involved (it likely is), but it would have saved me a lot of time if the LLVM upgrade had been mentioned (which it is for LLVM 11 in 1.47, BTW, but OTOH, now that I look, it appears the last upgrade mentioned is to LLVM 6 in 1.25...)
FWIW, the LLVM 11 upgrade in 1.47 got back a lot of the performance LLVM 10 lost:
Not for the testcase I'm bisecting, but that's OT.
I agree we should be mentioning this; thank you for noting it. I would be happy to accept a PR adding those in to the release notes (just 1.45 and 1.47, or more if you have the time).
Do you have an issue for that regression?
Will have when I have more information to feed into one.
Change:
<ins> // Copyright 2018 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. // no-prefer-dynamic #![crate_type = "proc-macro"] extern crate proc_macro; use proc_macro::TokenStream; #[proc_macro_derive(Foo)] pub fn foo(a: TokenStream) -> TokenStream { "".parse().unwrap() } #[proc_macro_derive(Bar, attributes(custom))] pub fn bar(a: TokenStream) -> TokenStream { "".parse().unwrap() } </ins>

Discussion:
Originally reported as this is reduced to: compiles with:
cc I'm not really sure what this classifies under, it seems like maybe although doesn't break it, only does. After though it may be broken by (I'm not 100% sure where this is happening)
I'm not really sure what this classifies under, it seems like maybe although doesn't break it This falls under and .
I hit this error last week when trying to update a crate that used 's derive macros. I found that ing the macro would give me the attribute error, but ing the crate worked.
I think that may be a separate bug, can you file a different issue? I believe I've fixed this issue in
Change:
<ins> // Make sure we don't ICE when an RPITIT captures more method args than the // trait definition, which is not allowed. Due to the default lifetime capture // rules of RPITITs, this is only doable if we use precise capturing. pub trait Foo { fn bar<'tr: 'tr>(&'tr mut self) -> impl Sized + use<Self>; //~^ ERROR `use<...>` precise capturing syntax is currently not allowed in return-position `impl Trait` in traits } impl Foo for () { fn bar<'im: 'im>(&'im mut self) -> impl Sized + 'im {} //~^ ERROR return type captures more lifetimes than trait definition //~| WARN impl trait in impl method signature does not match trait method signature } fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: expected lifetime parameter, but found another generic parameter', 'error: internal compiler error: expected lifetime parameter, but found another generic parameter' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of --
cc
Change:
<ins> fn main() { let _tmp = [ ("C200B40A82", 3), ("C200B40A83", 4) //~ ERROR: expected function, found `(&'static str, {integer})` [E0618] ("C200B40A8537", 5), ]; } </ins>

Discussion:
Given the following code (): The current output is: <!-- The following is not always necessary. --Ideally the output should look like: and the compiler would preview the fix, by adding the commas in green. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This week I'm busier than I thought ;) release-assignment
label +A-parser
claim
Change:
#include <cstdlib> #endif <ins> #include <iostream> </ins> //===----------------------------------------------------------------------=== // // This file defines alternate interfaces to core functions that are more

Discussion:
Related to . If a fatal error occurs in LLVM, the compiler exits with status 1. This is problematic, because if a test is expecting a compilation failure, the test could still pass. It also makes it difficult to test for the presence of ICEs in general. A simple fix would be to patch our copy of LLVM to exit with 101 (like ICEs) in , but any other ideas would be appreciated.
Those error functions all call , which sounds like it could be a great hook for us, but then that only calls . :/
There is  though, and that handler gets called first.
That sounds nice, but if we exit with 101 (or simply panic) in the handler won't we be skipping any other cleanup (, plus any future cleanup that gets there)? Or could we just call it in our handler? I'm interested in putting a patch together, but I'm unfamiliar with how we link Rust to C++. The error handler needs to be able to consume a .
We shouldn't do anything that looks like exception unwinding. See : I think we can call it -- it's publicly declared in . We might want to keep a note to make sure we check for new cleanup needed when we update LLVM though. We bridge C++ code in . You could just write our handler in C++ there, and add some C-FFI function for to call and hook that up.
Change:
debug!("Borrows::statement_effect: stmt={:?}", stmt); match stmt.kind { mir::StatementKind::Assign(ref lhs, ref rhs) => { <del> // Make sure there are no remaining borrows for variables // that are assigned over. self.kill_borrows_on_place(trans, lhs); </del> if let mir::Rvalue::Ref(_, _, ref place) = **rhs { if place.ignore_borrow( self.tcx,

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:
/// ``` #[stable(feature = "move_cell", since = "1.17.0")] pub fn into_inner(self) -> T { <del> unsafe { self.value.into_inner() } </del> <ins> self.value.into_inner() </ins> } }

Discussion:
It's been unsafe since 2014 when it was called . Nobody thought about it, I guess, but it shouldn't be unsafe.
For reference the PR which it is
Someone thought about it enough to : Has something changed to make this consideration unnecessary or do you have an explanation of why the reasoning is faulty?
Because the function takes so by definition it must be the owner of the value so there can be no other viewers, either from this thread or another thread.
Although this isn't backwards-compatible there is some prior art of going unsafe -safe: (although, that was pre-1.0)
That's weird, it seems like you ought to be able to assign a safe fn to an unsafe fn pointer. , Nicole Mazzuca wrote:
We removed the subtyping relation at some point; it does seem like a coercion would be (probably) ok, but that would still not be (strictly) backwards compatible.
(I tend to agree that could be safe, though, and I highly doubt any existing crates would actually break due to this change.)
We could always do a crater run just to be absolutely sure nobody is turning into a function pointer.
HI ! Any news on this one ?
No change that I know of.
FWIW the relevant coercion was in
This change is breaking my crate. If I add the then it will work for older compilers. If I remove the then it will work for newer compilers. Is there a conditional compilation attribute for compiler version? I can't find one.
Use
Yeah, that's what I'm doing for now. It seems kind of lame, though. But it does work.
Change:
} fulfill_cx.select_all_or_error(&infcx).is_ok() <del> }) </del> <ins> }); debug!("normalize_and_test_predicates(predicates={:?}) = {:?}", predicates, result); result </ins> } /// Given a trait `trait_ref`, iterates the vtable entries

Discussion:
Compiler panicks instead of showing an appropriate error message in case boundaries are not satisfied. I tried this code: In the result compiler panicked with the following message:
Minimal repr:
Still panics on stable 1.15.1
Change:
[[package]] name = "cargo_metadata" <del> version = "0.9.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "46e3374c604fb39d1a2f35ed5e4a4e30e60d01fab49446e08f1b3e9a90aef202" dependencies = [ "semver 0.9.0", "serde", "serde_derive", "serde_json", ] [[package]] name = "cargo_metadata" </del> version = "0.11.1" source = "registry+https://github.com/rust-lang/crates.io-index" checksum = "89fec17b16f1ac67908af82e47d0a90a7afd0e1827b181cd77504323d3263d35"

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. 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! And nominating for compiler team prioritization.
The bot is wrong; it's not that broke Miri, it's
Change:
blk_mode: BlockCheckMode, mut attrs: AttrVec, ) -> PResult<'a, P<Expr>> { <ins> if self.is_array_like_block() { if let Some(arr) = self.maybe_suggest_brackets_instead_of_braces(lo, attrs.clone()) { return Ok(arr); } } </ins> if let Some(label) = opt_label { self.sess.gated_spans.gate(sym::label_break_value, label.ident.span); }

Discussion:
I ended up spending way too much time debugging the following error, since I was trying to port some C code to rust. Give the error: The error message is very vague and hard to determine the actual error here. Seeing as though some programming languages like Java and C use for arrays, I think it'd make sense for the compiler to suggest using if the user is trying to create an array. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I suppose adding manual diagnostic somewhere around will get the job done. claim
Change:
<ins> // Copyright 2018 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. // compile-pass #![feature(extern_types)] extern { type Opaque; } const FOO: *const u8 = &42 as *const _ as *const Opaque as *const u8; fn main() { let _foo = FOO; } </ins>

Discussion:
At This is used by is_null() Backtrace: cc solson/miri
Minimal repro:
Change:
ConstraintCategory::Return => { err.span_note(constraint_span, "closure is returned here"); } <ins> ConstraintCategory::OpaqueType => { err.span_note(constraint_span, "generator is returned here"); } </ins> ConstraintCategory::CallArgument => { fr_name.highlight_region_name(&mut err); err.span_note(

Discussion:
emits the following error The correct code needs the to be part of the block because it is a stack allocation that needs to be in the generator: Ideally, the error message would mention : thanks to for bringing this up! CC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We could also consider suggesting an block, similar to the hints we provide for closures.
Marking this as a focus item. assign
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // compile-flags:-F private_no_mangle_fns </del> <ins> // compile-flags:-F private_no_mangle_fns -F no_mangle_const_items -F private_no_mangle_statics </ins> // FIXME(#19495) no_mangle'ing main ICE's. #[no_mangle] fn foo() { //~ ERROR function foo is marked #[no_mangle], but not exported } <ins> #[allow(dead_code)] #[no_mangle] const FOO: u64 = 1; //~ ERROR const items should never be #[no_mangle] #[no_mangle] pub const PUB_FOO: u64 = 1; //~ ERROR const items should never be #[no_mangle] </ins> #[no_mangle] pub fn bar()  { } <ins> #[no_mangle] pub static BAR: u64 = 1; #[allow(dead_code)] #[no_mangle] static PRIVATE_BAR: u64 = 1; //~ ERROR static PRIVATE_BAR is marked #[no_mangle], but not exported </ins> fn main() { foo(); bar();

Discussion:
Will not actually be exported in the resulting object. There are two obvious fixes, the first being to expand on my pub-not-exported lint to warn you that this will not work, the second being to fix the compiler to export the symbol with the appropriate value (Without altering the existing inlining behaviour, although it may give a more reasonable option for cases like trying to take the address of a item). Happy to work on either, although I would need a mentor for the second part.
I'm not sure what you mean by it not being exported. It might not be visible as a symbol (if you're linking with some C code or something), but you can certainly reference that item from another Rust crate.
Sorry for not being clear. That's exactly what I meant, the symbol is not visible in the resulting object. This is pretty confusing (I've been doing a lot of C(++) <-Rust lately and I'm trying to make the compiler warn people about all the things that have tripped me up)
I think the right option is to expand the lint. The whole difference between and is that the former isn't guaranteed to have a location in memory. To a C programmer it's like a variable.
Sounds totally reasonable. I'll expand the lint.
Ah, I see now. I didn't know there was a lint for on items that don't export a symbol. That explains a lot!