jiebi/CodeConvo huggingface dataset:
Change:
<ins> // missing and missing2 exist to make sure that the error only happens on a `main` declaration extern "C" { fn missing(); fn main(); //~^ the `main` function cannot be declared in an `extern` block fn missing2(); } </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. --Not minimal, but possibly helpful, 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. --: <!-- 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 --
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-low
This appears to have been caused by
claim
~A potential duplicate~
No that's a completely different error
Sorry I misread the error message, It is probably a duplicate of
Yep, that looks very similar
Change:
self.tcx.sess, self.tcx.span_of_impl(impl_def_id).unwrap(), E0119, "conflicting implementations of trait `{}`{}:", overlap.trait_desc, <del> overlap.self_desc.map_or(String::new(), |ty| format!(" for type `{}`", ty))); </del> <ins> overlap.self_desc.clone().map_or(String::new(), |ty| format!(" for type `{}`", ty))); </ins> match self.tcx.span_of_impl(overlap.with_impl) { Ok(span) => { <del> err.span_note(span, "conflicting implementation is here:"); </del> <ins> err.span_label(span, &format!("first implementation here")); err.span_label(self.tcx.span_of_impl(impl_def_id).unwrap(), &format!("conflicting implementation{}", overlap.self_desc .map_or(String::new(), |ty| format!(" for `{}`", ty)))); </ins> } Err(cname) => { err.note(&format!("conflicting implementation in crate `{}`",

Discussion:
From: src/test/compile- Error E0119 needs a spanlabel and a spannote converted to a span_label, updating it from: To:
Grabbed this one from the list.
Change:
<ins> // check-pass #![deny(dead_code)] enum Foo { Bar, } fn main() { let p = [0; 0]; p.bar(); } trait Bar { fn bar(&self) -> usize { 3 } } impl Bar for [u32; Foo::Bar as usize] {} </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code: I expected to see this happen: no warning is emitted. Instead, this happened: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
I'm not sure this needs to block , but it affects it, so marking as blocking for now.
claim
This is actually not an issue related to const generics :sweat_smile: It does not look at trait impls even if they are used as long as they don't overwrite the relevant method.
Change:
has_parens: bool, modifiers: BoundModifiers, ) -> PResult<'a, GenericBound> { <del> let lifetime_defs = self.parse_late_bound_lifetime_defs()?; let path = if self.token.is_keyword(kw::Fn) </del> <ins> let mut lifetime_defs = self.parse_late_bound_lifetime_defs()?; let mut path = if self.token.is_keyword(kw::Fn) </ins> && self.look_ahead(1, |tok| tok.kind == TokenKind::OpenDelim(Delimiter::Parenthesis)) && let Some(path) = self.recover_path_from_fn() {

Discussion:
The following code: currently produces a heap of semi-helpful diagnostics: <details<summary<bstderr (7 errors)</b</summary</detailswhen instead we could special-case this and emit a single (or at least fewer) diagnostic that suggests the following: If the bound in not inside , like in: we currently emit the following: which is less verbose for sure but still, we should provide the same suggestion I propose above. Related issue: . label A-parser A-suggestion-diagnostics D-newcomer-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Error: Parsing ping command in failed: ...'stbot ping' ''... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
I'd like to take a look. claim
I'm wondering if taking an approach that suggests using higher-rank trait bounds () for an Fn-family trait with a lifetime parameter. Is it appropriate? I'm concerned that it may not a comprehensive solution because HRTB can be used outside of the Fn-family traits (as I understand). Or is it okay only for the Fn-family traits for now?
I am not sure I fully understand what you mean. As you probably know, none of , , take a lifetime parameter and probably never will. Of course, you could define such a trait with unstable features but there is no way to use them, so it's not relevant: Yes, I'd say so. I wouldn't look for names however (like , , …) but just look for an opening parenthesis after a generic parameter list. This way, we can emit the same suggestion for the following case (where the name is ):
Ah, definitely. Thank you!
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> use ascii; </ins> use borrow::{Cow, ToOwned, Borrow}; use boxed::Box; use clone::Clone; use convert::{Into, From}; use cmp::{PartialEq, Eq, PartialOrd, Ord, Ordering}; use error::Error; <del> use fmt; </del> <ins> use fmt::{self, Write}; </ins> use io; use iter::Iterator; use libc;

Discussion:
CString should escape its contents like a byte string, not trying to show it as utf-8. Right now it does the latter via
For example, if the CString contains the byte , I would expect that to be visible in the Debug output.
Change:
|             ^^^^^^^^^^^^ help: try using one of the enum's variants | <del> LL |     let z = ManyVariants::Eight(); </del> <ins> LL |     let z = ManyVariants::One(); |             ^^^^^^^^^^^^^^^^^ LL |     let z = ManyVariants::Two(); |             ^^^^^^^^^^^^^^^^^ LL |     let z = ManyVariants::Three(); </ins> |             ^^^^^^^^^^^^^^^^^^^ <del> LL |     let z = ManyVariants::Five(); |             ^^^^^^^^^^^^^^^^^^ </del> LL |     let z = ManyVariants::Four(); |             ^^^^^^^^^^^^^^^^^^ <del> LL |     let z = ManyVariants::Nine(); |             ^^^^^^^^^^^^^^^^^^ </del> and 6 other candidates error: aborting due to 5 previous errors

Discussion:
The test appears to be intermittently changing its output. Usually, it prints: but sometimes it prints: See for an example of this happening. Here's a log snippet from a compiler build which prints (the current expected output): Note - this indicates that the chosen (which is what actually gets printed) is Output from a compiler which prints : Note - here, the is . There appears to be some non-determinism occuring, but I'm not sure where.
This is blocking - some builders are printing while others are printing , making it impossible to merge.
Change:
<ins> // check-pass #![deny(warnings)] pub struct Struct; impl Struct { #[allow(non_upper_case_globals)] pub const Const: () = (); } fn main() {} </ins>

Discussion:
I believe the old behavior from nightly-2023-04-19 is correct. The repro has nothing to do with trait impls so I believe was not supposed to have affected it.
Bisects to .
How on earth did that happen? It was like a five-line change. :laughing: EDIT: got a fix, will post soon.
Probably something to do with the hygeine of the span on the versus the . if you can't fix this then ping me and I'll look at it, but we probably should fix it sooner than later.
Actually, you're probably right.
Oh, no, that's not it. You're missing a call to in the visitor.
Change:
<ins> error[E0277]: the trait bound `&T: X` is not satisfied --> $DIR/issue-106443-sugg-clone-for-bound.rs:10:9 | LL |     foo(s); |         ^ the trait `X` is not implemented for `&T` | help: consider further restricting this bound | LL | fn bar<T: X + Clone>(s: &T) { |             +++++++ help: consider using clone here | LL |     foo(s.clone()); |          ++++++++ error[E0277]: the trait bound `&T: X` is not satisfied --> $DIR/issue-106443-sugg-clone-for-bound.rs:14:9 | LL |     foo(s); |         ^ the trait `X` is not implemented for `&T` | help: consider using clone here | LL |     foo(s.clone()); |          ++++++++ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
we should suggest cloning. Also, we should suggest <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
If we suggest add bound, we don't need dervie , This code will compile:
Change:
struct MyStruct { field: bool, inner_array: [char; 1], <ins> raw_ptr: *mut u8 </ins> } impl MyStruct { fn use_mut(&mut self) {} } const ARRAY: [u8; 1] = [25]; <del> const MY_STRUCT: MyStruct = MyStruct { field: true, inner_array: ['a'] }; </del> <ins> const MY_STRUCT: MyStruct = MyStruct { field: true, inner_array: ['a'], raw_ptr: 2 as *mut u8 }; const RAW_PTR: *mut u8 = 1 as *mut u8; </ins> fn main() { ARRAY[0] = 5; //~ WARN attempting to modify

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 have quite a lot of MMIO in an embedded project, defined and used like this: (see a ) When I , I'm getting a whole host of warnings of the type: I expect no warnings, because I'm not assigning to a , I'm assigning to a dereferenced , aka a mutable u32. I couldn't figure out a playground example that would show the value actually mutating, but by hitting hardware registers I can prove that the value does get mutated, and it makes sense that it would: The pointer is , but it's pointing to a able . Dereferencing shouldn't care whether the pointer variable is . <!-- 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. --: No backtrace for this bug; it's a warning.
There's a... fine, I guess, workaround of in my case, since all the MMIO code is bundled into a module away from the rest.
cc
This will be fixed by
Awesome, thanks so much!
Change:
} } <del> #[stable(feature = "rust1", since = "1.0.0")] impl<K, V, S, Q: ?Sized> IndexMut<Q> for HashMap<K, V, S> where K: Eq + Hash + Borrow<Q>, Q: Eq + Hash, S: HashState, { #[inline] fn index_mut<'a>(&'a mut self, index: &Q) -> &'a mut V { self.get_mut(index).expect("no entry found for key") } } </del> /// HashMap iterator. #[stable(feature = "rust1", since = "1.0.0")] pub struct Iter<'a, K: 'a, V: 'a> {

Discussion:
I believe we intend to eventually extend the index traits with the ability to override the syntax specifically using a trait like . This would allow hashmaps to be used like and have that insert the key, unlike today where will panic if is not already present. To pave the way, the simplest thing is to remove the operator from those collections where we would anticipate growing on demand. I believe that would be , , and possible and . Thoughts? cc
triage: P-backcompat-libs I-needs-decision (1.0 beta)
triage: P-backcompat-libs (1.0 beta)
I was just starting to prep a PR to resolve this by removing the impl, as you suggested. :)
Don't we want to keep the implementation on for example to do something like ?
Depending on the exact way that is done, it may not be possible to provide both modes of use. That is, we want to be able to write -- which we cannot today -- but it's not clear that you can do that and also support examples like the one you gave. In particular, that involves adjusting inference to determine whether or not a deref is in play. For now, removing these impls will give us the most freedom when we do incorporate .
It seems weird to have this and insert -- insert has a return value, though. This would be a super-annoying ergonomic regression in the interim. What's the expected timeline for something like IndexSet? 1.1?
Oh actually upon reflection most usages I know are Index, not IndexMut. Not as awful a regression.
It should be possible to move in, out, and take references with the operator. If that's not possible with the current design then the current design has to be changed instead of committing to yet another subpar design until 2.0.
sounds powerful and interesting, is there any RFC for it now?
It feels odd that does not support . I don't buy the argument that would be confused with - no other container supports insertion via the syntax. Now if you would add some hypothetical and support insertion into a via , then someone would just get confused that they can't use to insert into a .. (doesn't really makes sense, but what if entries are default constructible!) Not even talking about the pandora box of accidentally inserting elements into the container. Imho we should keep consistent as an accessor to get references to data already existing in the container.
Change:
<ins> error: `extern` block uses type `impl TraitA`, which is not FFI-safe --> $DIR/lint-ctypes-73251-2.rs:29:25 | LL |     pub fn lint_me() -> <AliasB as TraitB>::Assoc; |                         ^^^^^^^^^^^^^^^^^^^^^^^^^ not FFI-safe | note: the lint level is defined here --> $DIR/lint-ctypes-73251-2.rs:2:9 | LL | #![deny(improper_ctypes)] |         ^^^^^^^^^^^^^^^ = note: opaque types have no C equivalent error: aborting due to previous error </ins>

Discussion:
cc Gives the following incorrect warning:
I'm not sure if this is incorrect - I think this is what I'd expect. In the declaration of , we don't know what concrete type is - if it were , then we could normalize to - but we don't know? Maybe I'm missing something.
Hmm, that might be true. I definitely think that the following should not lint here (with bound to u32)
I agree that seems like it should be fine. So, this happens because of this call: It makes sense that we want to lint on opaque types on extern declarations, it's unclear whether we would want to allow projections which contain opaque types - this would solve the case you've shown here, but could be used to "sneak" opaque types by the lint (in , the projection normalizes to an opaque type; it's hard to detect because the normalization goes further and resolves it to so we can't tell that it was an opaque type) - I have a build with this locally. Any thoughts on whether we should change the behavior here? cc
Hm, I think it might be worth it to normalize using here, which should not normalize the first case and your example while fixing the second one if I am not mistaken.
Long ago I filed where we also concluded Reveal::UserFacing is the right behavior for normalization in this lint. The current behavior comes from cc
I'll put up a PR with my experiments from last night later in that case.
Change:
extern crate dep_2_reexport; extern crate dependency; <del> use dep_2_reexport::do_something; use dependency::Type; </del> <ins> use dep_2_reexport::Type; use dependency::{do_something, Trait}; </ins> fn main() { do_something(Type); <ins> Type.foo(); Type::bar(); </ins> }

Discussion:
I'm writing code for a programming language that uses two libraries: one for a (very simple) parser, and another for a lower level byte code, which also uses the same parser library. The parser library (TSPL) defines the trait, with the byte code library (HVM) defining a that implements that trait through a macro from TSPL. Then, a third library does something like this, where is a method from that trait: This works as expected if the dependencies in are defined like this: If we change to use the version from the latest git commit like this: Then the code does not compile anymore, even though the version in the main branch in git has the exact same code as the published version . We get an error and a warning: Notice that the compiler error tells us the function has been found from the package, and we do as the error message tells us (), but the compiler does not recognize the trait is being used even so. While writing this issue, I figured out the problem: uses the version from crates-io and our library doesn't and, even though they have the exact same code, the two versions of clash and the compiler does not compile. If we do something like this it works as expected: I still want to open this issue because I believe the error message could be more descriptive: in other cases where dependencies have clashing versions of other dependencies, usually Rust specifies it as such. The current error message is not very descriptive - the solution it gives to the problem does not work at all and may push users into the wrong direction. <!-- 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<summaryBacktrace</summary<p</p</details

Consider three crates High, Mid and Low, where: Mid depends on Low; High depends on both Mid and Low. This is a quite common case. Now, it sometimes happens that the dependency of Mid is bumped to a more recent version of Low. If, however, the developer fails to bump the dependency of High to a more recent version of Low, surprising error messages arise. In particular, may arise, without any change to the code of either or . It would be great if the compiler could detect the error and somehow print something along the liens of
Triage: I feel like this has gotten better in certain cases, but not all. It would be nice to make a way to reproduce this more easily, but it's non-trivial.
Change:
} }; <ins> let alloc = self.memory.get_raw(ptr.alloc_id)?; </ins> match mplace.layout.abi { Abi::Scalar(..) => { <del> let scalar = self.memory.get_raw(ptr.alloc_id)?.read_scalar( self, ptr, mplace.layout.size, )?; </del> <ins> let scalar = alloc.read_scalar(self, ptr, mplace.layout.size)?; </ins> Ok(Some(ImmTy { imm: scalar.into(), layout: mplace.layout })) } Abi::ScalarPair(ref a, ref b) => {

Discussion:
I tried this code: I expected the code to fail to compile with a cycle error. Instead, it compiled and ran,printing the value of . I was able to verify that this bug happens for the 1.42.0 stable, 1.43-beta.5, and 1.44.0-nightly(2020-04-11 ) versions. Trying this code in it errors up to 1.36.0,and doesn't error anymore from 1.37.0 onwards.
cc
narrowed to the following: Auto merge of - petrochenkov:builtout, r=eddyb Auto merge of - luca-barbieri:optimize-refcell-borrow, r=RalfJung Auto merge of - Centril:rollup-, r=Centril Auto merge of - petrochenkov:rpass, r=Centril Possibly ?
Weaponized soundness hole (using as a foundation): ==
cc
oopsie yeah... is probably where this started. But that is crucial to fix The problem is that "reading from a ZST" isn't actually doing anything. Here's the MIR for : So there actually is a that loads from this static (I didn't expect that). But in Miri, a ZST load just checks that the address is in-bounds; no actual access to the underlying memory happens so there is no cycle error.
Assigning as and removing .
Change:
<ins> // check-pass #![feature(never_type)] #[derive(Copy, Clone)] pub enum E { A(!), } pub union U { u: (), e: E, } pub const C: () = { let E::A(ref a) = unsafe { &(&U { u: () }).e}; }; fn main() {} </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. --<!-- 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
seem like options that when paired together would cause issues... At first glance, I'm actually not sure why this is filed as a bug.
I agree. Nobody should be testing , I don't know why those passes are even in the codebase. But this is a bug. I've found this in real code with a much smaller set of flags: And this bisects to Bisected by hand, there's no nightly with that PR yet. Don't know where Matthias got that toolchain.
Afaict likes to do ICE testing against master
We just hit this on Fuchsia as well. I think we should revert the PR until we fix this issue and reland it.
Another one with
Also here's a list of files from the rustc repo that all seem to trigger the problem in one way or another
Looks like there is one more issue in GVN ():
There is no basis for the assumption that interpreter will never downcast to an uninhabited variant:
nice example! That assert was as an experiment to see if we ever hit that codepath, and it seems like the answer is yes. It should thus be removed, with a suitable const-eval test case.
I wonder if that code shouldn't have a read somewhere though... it is conceptually a match after all. Still, the assertion should go: That adds test, but not the others.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
... LL |     let d = unsafe { *const_ptr() }; |                      ------------ you could clone this value <del> help: consider removing the dereference here | LL -     let d = unsafe { *const_ptr() }; LL +     let d = unsafe { const_ptr() }; | </del> error: aborting due to 4 previous errors; 1 warning emitted

Discussion:
Cloning the pointer doesn't make sense in that situation and would cause a type mismatch error. I'm not sure whether any of the two current suggestions should be kept or removed in this case. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that this works: It works because is a place expression and then we attach to that, which then reborrows the String. I don't think we should suggest , which may have undesirable or unexpected effects in the case of things like types that handle backing buffers, instead of issuing a safe which will recreate the backing allocation correctly.
I didn't know that was possible, thanks for letting me know. I guess that the best approach would then be to change the suggestion accordingly as below?
Correct. Also, we could mention in the error for pointers, but we shouldn't recommend it. It's unsafe code, we should strive to preserve the "you break it, you buy it" / "do your own research" experience for that.
The relevant section of diagnostic code is here but it will require some restructuring to account for the fact that the suggestion will not be doing things like stripping parentheses, but suggesting adding them if they don't exist.
claim It looks good for me to make a try.
Change:
<ins> #![crate_name = "foo"] pub mod sub { pub struct Item; pub mod prelude { pub use super::Item; } } // @count foo/index.html '//a[@class="mod"][@title="foo::prelude mod"]' 1 // @count foo/prelude/index.html '//div[@class="item-row"]' 0 pub mod prelude {} #[doc(inline)] pub use sub::*; </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --If glob reexport reexports module and there is already module , the documentation duplicates. Current behaviour: ! ( module is duplicated, though both module links point to as expected) The expected behaviour: module is only shown once. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim