jiebi/CodeConvo huggingface dataset:
Change:
} #[lang = "eh_personality"] extern fn rust_eh_personality() {} <del> #[lang = "panic_fmt"] extern fn rust_begin_panic() -> ! { loop {} } </del> <ins> #[lang = "panic_fmt"] extern fn rust_begin_panic() -> ! { unsafe { intrinsics::abort() } } </ins> # #[lang = "eh_unwind_resume"] extern fn rust_eh_unwind_resume() {} # #[no_mangle] pub extern fn rust_eh_register_frames () {} # #[no_mangle] pub extern fn rust_eh_unregister_frames () {}

Discussion:
The following file, when compiled without optimizations, correctly generates an overflow check in : However, compiling with optimizations plus or generates code without the overflow check. However, if I move to a separate no_core crate like this, the issue disappears and the overflow check is generated:
noticed that my panic implementation () is UB according to LLVM (see ), so it optimizes the overflow check out on the assumption that it can never be triggered (since that would be UB). Replacing it with e.g. fixes the issue.
Change:
// require LTO so the request for LTO is always unconditionally // passed down to the backend, but we don't actually want to do // anything about it yet until we've got a final product. <del> let is_rlib = cgcx.crate_types.len() == 1 && cgcx.crate_types[0] == CrateType::Rlib; </del> <ins> let is_rlib = sess_crate_types.len() == 1 && sess_crate_types[0] == CrateType::Rlib; </ins> <del> // Metadata modules never participate in LTO regardless of the lto // settings. let lto_type = if module.kind == ModuleKind::Metadata { ComputedLtoType::No } else { match cgcx.lto { Lto::ThinLocal if !linker_does_lto && !is_allocator => ComputedLtoType::Thin, Lto::Thin if !linker_does_lto && !is_rlib => ComputedLtoType::Thin, Lto::Fat if !is_rlib => ComputedLtoType::Fat, _ => ComputedLtoType::No, } }; </del> <ins> match sess_lto { Lto::ThinLocal if !linker_does_lto && !is_allocator => ComputedLtoType::Thin, Lto::Thin if !linker_does_lto && !is_rlib => ComputedLtoType::Thin, Lto::Fat if !is_rlib => ComputedLtoType::Fat, _ => ComputedLtoType::No, } } fn execute_optimize_work_item<B: ExtraBackendMethods>( cgcx: &CodegenContext<B>, module: ModuleCodegen<B::Module>, module_config: &ModuleConfig, ) -> Result<WorkItemResult<B>, FatalError> { let diag_handler = cgcx.create_diag_handler(); unsafe { B::optimize(cgcx, &diag_handler, &module, module_config)?; } // After we've done the initial round of optimizations we need to // decide whether to synchronously codegen this module or ship it // back to the coordinator thread for further LTO processing (which // has to wait for all the initial modules to be optimized). let lto_type = compute_per_cgu_lto_type(&cgcx.lto, &cgcx.opts, &cgcx.crate_types, module.kind); </ins> // If we're doing some form of incremental LTO then we need to be sure to // save our module to disk first.

Discussion:
First compile is ok, after I modify some contents. It failed. I've to . Then works.
I don't know how to setup a minimal env to reproduce this. But I'd love to provide any info you needed.
cc Is this maybe related to ? (Although this sounds like the opposite of that, where it is missing the bit code.)
Some digging shows that this is a preexisting bug in rustc: I believe that this is only showing up now because Cargo is only just now passing
I've posted a fix for this at
Change:
.map(|method| resolve_ty(method.ty))) } <ins> pub fn errors_since_creation(&self) -> bool { self.tcx.sess.err_count() - self.err_count_on_creation != 0 } </ins> pub fn node_type(&self, id: ast::NodeId) -> Ty<'tcx> { match self.tables.borrow().node_types.get(&id) { Some(&t) => t, // FIXME <del> None if self.tcx.sess.err_count() - self.err_count_on_creation != 0 => </del> <ins> None if self.errors_since_creation() => </ins> self.tcx.types.err, None => { self.tcx.sess.bug(

Discussion:
I have encountered this problem several times while compiling versions of rustc with errors, but this is the first self-contained example I have found. A single error as the field does not exist Note the fat cascading region error. This reproduces on 1.5/1.6 and current nightly.
cc
Change:
<ins> //~ ERROR: cycle detected //! Safe transmute did not handle cycle errors that could occur during //! layout computation. This test checks that we do not ICE in such //! situations (see #117491). #![crate_type = "lib"] #![feature(transmutability)] #![allow(dead_code, incomplete_features, non_camel_case_types)] mod assert { use std::mem::{Assume, BikeshedIntrinsicFrom}; pub struct Context; pub fn is_maybe_transmutable<Src, Dst>() where Dst: BikeshedIntrinsicFrom<Src, Context>, { } } fn should_pad_explicitly_packed_field() { #[repr(C)] struct ExplicitlyPadded(ExplicitlyPadded); //~^ ERROR: recursive type assert::is_maybe_transmutable::<ExplicitlyPadded, ()>(); } </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'not implemented: Cycle'', 'thread 'rustc' panicked at 'not implemented: Cycle'' 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
/ ping :grin:
Change:
extern { const i: isize; <del> //~^ ERROR expected one of `fn`, `pub`, `static`, `unsafe`, or `}`, found `const` </del> <ins> //~^ ERROR expected one of `fn`, `pub`, `static`, or `}`, found `const` </ins> }

Discussion:
This code produces "error: expected one of , , , or , found ":
That code sample probably didn't require linking to a playpen, I've made the description and title more useful.
Change:
resolve_associated_item(tcx, &item, param_env, trait_def_id, substs) } else { let ty = tcx.type_of(def_id); <del> let item_type = tcx.trans_apply_param_substs(substs, &ty); </del> <ins> let item_type = tcx.trans_apply_param_substs_env(substs, param_env, &ty); </ins> let def = match item_type.sty { ty::TyFnDef(..) if {

Discussion:
Compiling v0.2.10 and v0.4.4 with , I get the following ICEs:
reproduction:
Change:
<ins> // Copyright 2017 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. fn main() { println!("Test", 123, 456, 789); println!("Test2", 123, 456, 789 ); println!("Some stuff", UNUSED="args"); println!("Some more $STUFF", "woo!", STUFF= "things" , UNUSED="args"); } </ins>

Discussion:
After , the output for errors looks like: that's a lot of lines dedicated to underlining macro acruments. They should all be output in one multispan. cc
Hum indeed. If no one has taken it in 12 hours, I'll give it a look.
I'm poking at it right now. I think I need to fix 's methods to accept instead of just , and then I can use directly. After all, I created the problem, I should probably fix it. :P
Perfect. Good luck! :)
I believe this should be closed.
Hold on, it seems the PR is still open.
Seeing as there isn’t anyone working on this anymore, I’ll be happy to take over. This is my first issue, (woot), so I’m not exactly sure where to start. I assume I should just fork the repo, change to use , and fix the tests? Pinging and in case you want to work on this still.
I am not working on this anymore.
Those steps may be correct; or someone else may be able to verify for you. You can also look at and which appear to be previous PRs which attempted to do this. Let us know if you'd like any help!
Awesome! I'm super excited. Anyone specific I should ?
bors will select someone automatically if you don't specify anyone, but I think any of me, or would be available for review and or guidance.
For some reason I seem to be getting unrelated to my changes. (ran )
Those tests shouldn't actually be running in ... cc For these changes, I would suggest , I think that should be enough.
Gotcha, it’s possible I copy pasted from the wrong command (on mobile can’t check right now), but I’ll use that command for testing and see if it works. I’m kinda busy for the rest of the week but I’ll keep working on it in my free time. I’ll comment here until I get a PR ready with any updates I have.
Change:
// return slot alloca. This can cause errors related to clean-up due to // the clobbering of the existing value in the return slot. fn has_nested_returns(tcx: &ty::ctxt, cfg: &cfg::CFG, blk_id: ast::NodeId) -> bool { <del> for n in cfg.graph.depth_traverse(cfg.entry) { </del> <ins> for index in cfg.graph.depth_traverse(cfg.entry) { let n = cfg.graph.node_data(index); </ins> match tcx.map.find(n.id()) { Some(ast_map::NodeExpr(ex)) => { if let ast::ExprRet(Some(ref ret_expr)) = ex.node {

Discussion:
Notably, this does not occur with a trait like: This smells like a bug to me, unless a language change introduced special treatment of with regard to lifetimes.
An interesting quirk is that if you replace with just , it compiles fine with the impl.
cc
are you saying this used to work? Just curious what the original was.
(Also it seems difficult if not impossible to satisfy the combination of and ..... well I guess of static would, but I don't know if we can deduce that.
Yes, this used to work. This bug is affecting
It looks like this may have been introduced in . Prior to this, checking for bounds in was done via , which creates a throw-away inference context before calling into trait selection. It now goes through the ; the impl of for uses its own inference context. This causes region constraints introduced during trait selection for to stick around, resulting in a seemingly inappropriate transitive constraint between the free region within the closure body and at the call site of .
hmm good catch, sorry I let this slip through last week :( I'll try to pay it some attention now. The current code does not seem entirely wrong to me, though. I have to think this through a bit.
Change:
<ins> warning: unresolved link to `m` --> $DIR/disambiguator-macro-endswith-exclamatory.rs:3:6 | LL | //! [macro@m!] |      ^^^^^^^^ no item named `m` in scope | = note: `macro_rules` named `m` exists in this crate, but it is not in scope at this link's location = note: `#[warn(rustdoc::broken_intra_doc_links)]` on by default warning: 1 warning emitted </ins>

Discussion:
<!-- 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. --Occurs on stable + nightly : : i replaced backtrace with for readability since it's displayed without any flags: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
The combination of course seems invalid, but the compiler shouldn't panic, right?
That was quick, thank you!
Change:
name = "clippy" version = "0.0.212" dependencies = [ <del> "cargo_metadata", </del> <ins> "cargo_metadata 0.9.0", </ins> "clippy-mini-macro-test", "clippy_lints", "compiletest_rs",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver 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! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium. Removing I-nominated.
There is opening PR to fix this:
Change:
pub trait AmbiguousBoundTrait<'a, 'b>: 'a + 'b {} pub struct AmbiguousBoundWrapper<'a, 'b, T: ?Sized + 'a + 'b>(&'a T, &'b T); <ins> // Trait objects inside of another trait object, a trait bound or an associated type. pub trait Inner {} pub trait Outer<T: ?Sized> {} pub trait Base { type Type<T: ?Sized>; } impl Base for () { type Type<T: ?Sized> = (); } pub type NestedTraitObjects = dyn Outer<dyn Inner>; pub fn apit_rpit(o: impl Outer<dyn Inner>) -> impl Outer<dyn Inner> { o } pub type AssocTy = <() as Base>::Type<dyn Inner>; </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. --I found out about the ICE when my crate could not have its documentation online on (). I managed to narrow it down to the code below. All of the code here builds fine (, ), but on the latest stable and nightly it fails when doing . Originally, came from a separate crate, . To my surprise, using the dependency instead of replicating the symbols to this crate results in a more informative top-level error message of the ICE. With we can instead do: The full project can also be found in . Reproduced on more than one toolchain and platform, among which: Without the dependency: with the dependency : <!-- 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 --
this went build -ice in Regression in
is , cc author:
claim
Minimized: label S-has-mcve A-cross-crate-reexports
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Keeping it open until the fix is backported to beta.
The fix has been backported to beta () and to stable (). Closing.
Change:
CEnum(ity, min, max) => { assert_discr_in_range(ity, min, max, discr); Store(bcx, C_integral(ll_inttype(bcx.ccx(), ity), discr as u64, true), <del> val) </del> <ins> val); </ins> } General(ity, ref cases, dtor) => { if dtor_active(dtor) {

Discussion:
The attached source produces code that misbehaves on some platforms that are picky about memory access alignment. The code should exit with code 2, but on both Emscripten-generated JavaScript and ARMv5, it finishes with exit code 1 to indicate that the field is incorrectly tested as equal to . Changing the field to a type results in proper execution on these platforms. All optimization levels seem to cause it. Libraries that make use of structs with fields followed by enums seem particularly prone to this problem. It all works fine on platforms that allow unaligned memory access like x86, ARMv6, etc. Expected output: (x86, ARMv6) Actual output: (ARMv5, Emscripten) Note that the same ARM binary runs on both ARMv5 and ARMv6 platforms, producing the different results. See also: ( and removed)
To quote myself:
Change:
} } <ins> #[stable(feature = "vec_as_mut", since = "1.5.0")] impl<T> AsMut<Vec<T>> for Vec<T> { fn as_mut(&mut self) -> &mut Vec<T> { self } } </ins> #[stable(feature = "rust1", since = "1.0.0")] impl<T> AsRef<[T]> for Vec<T> { fn as_ref(&self) -> &[T] {

Discussion:
In I have this trait like this: I'd like to switch the bound on to be , but then I can no longer use a bare for , because there is currently no . It seems to me that such an impl ought to exist, especially because already exists.
Yes, and .
Since it landed now, it should appear first in Rust 1.5 (and will be stable).
Thank you!
Change:
pub fn dummy() {} // ensure that `extern crate foo;` was inserted into code snips automatically: <del> // @matches foo/index.html '//a[@class="test-arrow"][@href="https://example.com/?code=%23!%5Ballow(unused)%5D%0Aextern%20crate%20foo%3B%0Afn%20main()%20%7B%0Ause%20foo%3A%3Adummy%3B%0Adummy()%3B%0A%7D&edition=2015"]' "Run" </del> <ins> // @matches foo/index.html '//a[@class="test-arrow"][@href="https://example.com/?code=%23!%5Ballow(unused)%5D%0Aextern%20crate%20r%23foo%3B%0Afn%20main()%20%7B%0Ause%20foo%3A%3Adummy%3B%0Adummy()%3B%0A%7D&edition=2015"]' "Run" </ins>

Discussion:
In I tried to create a new testcase that runs doctests. However having the substring in a doctest comment injected an invalid into the code generated for the doctest. Turns out this here is a bit too aggressive: It looks like compiletest actually gave the crate the name , perhaps because it was defined in a file, and having a doctest such as this triggers the this auto-injection, resulting in a failed doctest run: /// // ^ line 10 /// assert_eq!(1, 1); /// `
I think rustdoc needs to check if the crate name is a keyword and add if so. Actually it's probably enough to unconditionally add since it works for things that aren't keywords.
there is actually two bugs here. not being properly escaped is one thing, the other is probably the way that rustdoc is invoked, or not quite sure. Basically it infers the crate name from the file name if not explicitly given, and then just assumes that a crate with that name exists, which it doesn’t.
that's an issue with compiletest, not rustdoc - it needs to compile the crate itself before running rustdoc on it: I don't know how to fix that, I think compiletest needs to add support for this maybe?
Change:
} fn main() { <ins> // test the values themselves, and autoderef. </ins> 1u32.method(); //~^ HELP following traits are implemented but not in scope, perhaps add a `use` for one of them //~^^ ERROR does not implement //~^^^ HELP `foo::Bar` //~^^^^ HELP `no_method_suggested_traits::foo::PubPub` <ins> std::rc::Rc::new(&mut Box::new(&1u32)).method(); //~^ HELP following traits are implemented but not in scope, perhaps add a `use` for one of them //~^^ ERROR does not implement //~^^^ HELP `foo::Bar` //~^^^^ HELP `no_method_suggested_traits::foo::PubPub` </ins> 'a'.method(); //~^ ERROR does not implement //~^^ HELP the following trait is implemented but not in scope, perhaps add a `use` for it: //~^^^ HELP `foo::Bar` <ins> std::rc::Rc::new(&mut Box::new(&'a')).method(); //~^ ERROR does not implement //~^^ HELP the following trait is implemented but not in scope, perhaps add a `use` for it: //~^^^ HELP `foo::Bar` </ins> 1i32.method(); //~^ ERROR does not implement //~^^ HELP the following trait is implemented but not in scope, perhaps add a `use` for it: //~^^^ HELP `no_method_suggested_traits::foo::PubPub` <ins> std::rc::Rc::new(&mut Box::new(&1i32)).method(); //~^ ERROR does not implement //~^^ HELP the following trait is implemented but not in scope, perhaps add a `use` for it: //~^^^ HELP `no_method_suggested_traits::foo::PubPub` </ins> <del> 1u64.method(); </del> <ins> Foo.method(); //~^ ERROR does not implement //~^^ HELP following traits define a method `method`, perhaps you need to implement one of them //~^^^ HELP `foo::Bar` //~^^^^ HELP `no_method_suggested_traits::foo::PubPub` //~^^^^^ HELP `no_method_suggested_traits::reexport::Reexported` //~^^^^^^ HELP `no_method_suggested_traits::bar::PubPriv` //~^^^^^^^ HELP `no_method_suggested_traits::qux::PrivPub` //~^^^^^^^^ HELP `no_method_suggested_traits::quz::PrivPriv` std::rc::Rc::new(&mut Box::new(&Foo)).method(); </ins> //~^ ERROR does not implement //~^^ HELP following traits define a method `method`, perhaps you need to implement one of them //~^^^ HELP `foo::Bar`

Discussion:
E.g. (The repetition is .) However, all of these are useless: because one cannot implement them for anyway, it would be better to just filter them out, e.g. reject external traits when the self type itself is external. cc
Good point, although it's not always as simple as that -- with multidispatch it is plausible you COULD implement the trait for if another type parameter were local, though not with the current orphan rules. Nonetheless, it might be good to just screen them out anyway, as it is unlikely to be what you plan to do.
Change:
/// and possibly other factors. Using linear search, searching for a random element is expected /// to take O(B log<sub>B</sub>n) comparisons, which is generally worse than a BST. In practice, /// however, performance is excellent. <ins> /// /// It is a logic error for a key to be modified in such a way that the key's ordering relative to /// any other key, as determined by the `Ord` trait, changes while it is in the map. This is /// normally only possible through `Cell`, `RefCell`, global state, I/O, or unsafe code. </ins> #[derive(Clone)] #[stable(feature = "rust1", since = "1.0.0")] pub struct BTreeMap<K, V> {

Discussion:
Collections that perform lookups based on a given property (e.g. a hash or an ordering) can be put into an inconsistent state when the property changes while its corresponding item is in the collection. This is normally not a problem, because such collections (at least those in ) do not provide mutable access to the type from which the property is derived (keys in the case of maps, items in the case of sets), but types with interior mutability can induce this behavior in safe code: Output: This is obvious from the definition of interior mutability, but it's definitely a footgun. If the use of such keys cannot be prevented with the type system, the collections should at least document that the property must remain constant for the duration of the item's presence in the collection. For example, Java's contains the following note:
This is a dupe of , which was for reasons in the thread itself. I believe the gist of the conversion was that yes, this can happen. Our implementations should ensure that this does not cause memory unsafety, but otherwise these sorts of "odd assertions" are ok to happen as this should be quite a rare occurrence anyway.
I still think the collection documentation needs to identify this problem. On Friday, March 13, 2015, Alex Crichton wrote:
Hm good point! I've an appropriate tag.
I'm working on a patch to document this.
Change:
#[derive(Clone, Copy, PartialEq, Eq, PartialOrd, Ord, Hash)] pub struct Term<'tcx> { <del> ptr: NonZeroUsize, </del> <ins> ptr: NonNull<()>, </ins> marker: PhantomData<(Ty<'tcx>, Const<'tcx>)>, } <ins> #[cfg(parallel_compiler)] unsafe impl<'tcx> rustc_data_structures::sync::DynSend for Term<'tcx> where &'tcx (Ty<'tcx>, Const<'tcx>): rustc_data_structures::sync::DynSend { } #[cfg(parallel_compiler)] unsafe impl<'tcx> rustc_data_structures::sync::DynSync for Term<'tcx> where &'tcx (Ty<'tcx>, Const<'tcx>): rustc_data_structures::sync::DynSync { } unsafe impl<'tcx> Send for Term<'tcx> where &'tcx (Ty<'tcx>, Const<'tcx>): Send {} unsafe impl<'tcx> Sync for Term<'tcx> where &'tcx (Ty<'tcx>, Const<'tcx>): Sync {} </ins> impl Debug for Term<'_> { fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result { let data = if let Some(ty) = self.ty() {

Discussion:
and currently store pointers as , which is not ideal: They should really work with pointers and strict provenance APIs like , , etc. See a PR fixing a similar issue for some context: (note: in that one I ended up rewriting the whole thing, I think this issue requires far less changes). <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
(I do plan to work on this, but if you want to work on this instead — feel free to , I can mentor you) <subcc
claim
Could you briefly describe and , also a comprehensive insight about this issue would greatly help, although I had a look at which currently is an . If I understand correctly, we are building a for this and aim to improve existing implementations as seen in languages like C++ by making it more strict, and there is some discussion that can basically do most of what C++ can and this addition might have some diverging path. Let me know, so I can move forward!
claim
Hi strict provenance means that we aren't doing pointer-int conversions and only operate through pointer types like suggested by OP. and currently use which doesn't work under strict provenance. If you'd like I can work on this issue.
Did you mean to mentor me for the same? I would be happy to learn!
is already working on this issue, is this right? Let's not override other people working on it already unless they agree or it's been several weeks with no response.
Hi yes I am working on this issue. This is my first time contributing so it will take me sometime. I will reassign the issue to me.
claim
Hi Just checking in :) Are you still working on this issue?
Yup I am still working on this issue :)
Let us know on Zulip if you need any help
with this resolved, I think rustc is free from "fuzzy provenance casts" :)
Awesome :-)