jiebi/CodeConvo huggingface dataset:
Change:
<del> error: expected one of `!`, `.`, `::`, `;`, `?`, `{`, `}`, or an operator, found `<-` </del> <ins> error: unexpected token: `<-` </ins> --> $DIR/bad.rs:5:7 | LL |     x <- y; <del> |       ^^ expected one of 8 possible tokens here </del> <ins> |       ^^ help: if you meant to write a comparison against a negative value, add a space in between `<` and `-` | LL |     x < - y; |       ^^^ </ins> error: expected expression, found keyword `in` --> $DIR/bad.rs:10:5

Discussion:
produces: It would be nice if it produced a suggestion to split it up: (This , but was broken in a previous change.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Hi I'd like to try this one. Just found the removed suggestion.
claim
assign Hmm, triagebot is not well...
It doesn't look like you're still working on this. Is it ok if I take over?
Sure. Thanks for your help.
Change:
found: &fmt::Display) -> &mut DiagnosticBuilder<'a> { <ins> self.note_expected_found_extra(label, expected, found, &"", &"") } pub fn note_expected_found_extra(&mut self, label: &fmt::Display, expected: &fmt::Display, found: &fmt::Display, expected_extra: &fmt::Display, found_extra: &fmt::Display) -> &mut DiagnosticBuilder<'a> { </ins> // For now, just attach these as notes <del> self.note(&format!("expected {} `{}`", label, expected)); self.note(&format!("   found {} `{}`", label, found)); </del> <ins> self.note(&format!("expected {} `{}`{}", label, expected, expected_extra)); self.note(&format!("   found {} `{}`{}", label, found, found_extra)); </ins> self }

Discussion:
This code is wrong, but the error message is confusing: Because I used accidentally as a type name when not using the right syntax ... this is pretty confusing:
One solution would be to add detail after the expected/found lines if primitive shadowing has come into play. This would not change the language, but make the error look like:
Change:
# aarch64-unknown-linux-gnu configuration CROSS_PREFIX_aarch64-unknown-linux-gnu=aarch64-linux-gnu- CC_aarch64-unknown-linux-gnu=gcc <del> LINK_aarch64-unknown-linux-gnu=gcc </del> CXX_aarch64-unknown-linux-gnu=g++ CPP_aarch64-unknown-linux-gnu=gcc -E AR_aarch64-unknown-linux-gnu=ar

Discussion:
Appears like: Essentially, 'LINK_foo' is empty. Heres a list:
I think this is your issue. (I ran into it myself while doing a build)
Dup of , apparently.
I believe this will be fixed by
Closing as a duplicate.
Change:
TermKind::Ty(ty) => { // Ensure we can use the tag bits. assert_eq!(mem::align_of_val(&*ty.0.0) & TAG_MASK, 0); <del> (TYPE_TAG, ty.0.0 as *const WithCachedTypeInfo<ty::TyKind<'tcx>> as usize) </del> <ins> (TYPE_TAG, NonNull::from(ty.0.0).cast()) </ins> } TermKind::Const(ct) => { // Ensure we can use the tag bits. assert_eq!(mem::align_of_val(&*ct.0.0) & TAG_MASK, 0); <del> (CONST_TAG, ct.0.0 as *const WithCachedTypeInfo<ty::ConstData<'tcx>> as usize) </del> <ins> (CONST_TAG, NonNull::from(ct.0.0).cast()) </ins> } }; <del> Term { ptr: unsafe { NonZeroUsize::new_unchecked(ptr | tag) }, marker: PhantomData } </del> <ins> Term { ptr: ptr.map_addr(|addr| addr | tag), marker: PhantomData } </ins> } }

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 :-)
Change:
<ins> // Copyright 2016 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-flags: -Z parse-only fn foo() { } //! Misplaced comment... //~^ ERROR expected outer doc comment //~| NOTE inner doc comments like this (starting with `//!` or `/*!`) can only appear before items fn main() { } </ins>

Discussion:
This piece of code fails compilation (): This is because the compiler expects inner comments only before the first item (something like ). It doesn't point this out however, instead, it gives the rather cryptic error message: It should say something like "Please place the inner comment to the top". From reading the code, an error message like would be sufficient. Can that be achieved by changing the if near line 38: to something like ? I haven't tested because I haven't set up a development setup of rustc (and don't know whether there is a better way to do it).
It was suggested on irc to cc about this because its a bad error.
Change:
// Put the value 0x200 in eax asm!("mov $$0x200, %eax" : /* no outputs */ : /* no inputs */ : "eax"); # } } <ins> # #[cfg(not(any(target_arch = "x86", target_arch = "x86_64")))] # fn main() {} </ins> ``` Input and output registers need not be listed since that information

Discussion:
Triggers an LLVM assertion when targeting Android:
Something that works on any host (i.e. you needn’t compile libstd for android to repro):
As the error says, isn't a supported calling convention for the ARM target in LLVM. Not really much we can do from the rustc side unless we want to error early based on cc/target combinations. In any case, it should not crash.
I'm hitting this when I tried to run tests for 1.10.0 on arm64 (aarch64-unknown-linux-gnu). The build succeeds otherwise. I'm just adding and to for the time being.
Neither example crashes today. Closing, since I don't see any good opportunity for a test here (it'd have to be something like and that's probably not worth it). With (original example): Updated example:
Change:
mir::ProjectionElem::Index(ref index) => { let index = self.trans_operand(bcx, index); let llindex = self.prepare_index(bcx, index.immediate()); <del> (build::InBoundsGEP(bcx, tr_base.llval, &[llindex]), </del> <ins> let zero = common::C_uint(bcx.ccx(), 0u64); (build::InBoundsGEP(bcx, tr_base.llval, &[zero, llindex]), </ins> ptr::null_mut()) } mir::ProjectionElem::ConstantIndex { offset,

Discussion:
will fail to compile with an LLVM abort: Seems to be a mis-translation of indexing (trans/mir/lvalue at ).
This is not related to According to we might do something incorrectly with GEPs.
That was my first guess, but it seems that is an rvalue with the type , suggesting itself was loaded.
Oh, my first guess was right: all GEPs are but that's not enough. You see, GEP's first index is for the pointer itself. currently gets (mistakenly) translated as instead of the (correct) . All GEP calls should use as the first index and then the index of the array element/struct field.
Change:
e.note( "the macro call doesn't expand to an expression, but it can expand to a statement", ); <del> e.span_suggestion_verbose( site_span.shrink_to_hi(), "add `;` to interpret the expansion as a statement", ";", Applicability::MaybeIncorrect, ); </del> <ins> if parser.token == token::Semi { if let Ok(snippet) = parser.sess.source_map().span_to_snippet(site_span) { e.span_suggestion_verbose( site_span, "surround the macro invocation with `{}` to interpret the expansion as a statement", format!("{{ {}; }}", snippet), Applicability::MaybeIncorrect, ); } } else { e.span_suggestion_verbose( site_span.shrink_to_hi(), "add `;` to interpret the expansion as a statement", ";", Applicability::MaybeIncorrect, ); } </ins> } }, _ => annotate_err_with_kind(&mut e, kind, site_span),

Discussion:
or perhaps The bad help isn't related to the choice of or (even though the former needs to be followed by to be a statement and the latter doesn't, which could explain the source of the hint); also generates the help to add . %20%3D%3E%20%7B%3B%7D%3B%0A%7D%0A%0Afn%20main()%20%7B%0A%20%20%20%20let%20%20%3D%20statement!()%3B%0A%7D%0A) No response modify labels +D-incorrect <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
for ( elem in vec ) { //~^ ERROR expected one of `)`, `,`, `@`, or `|`, found keyword `in` <del> //~| ERROR unexpected closing `)` </del> <ins> //~| ERROR unexpected parenthesis surrounding `for` loop head </ins> const RECOVERY_WITNESS: () = 0; //~ ERROR mismatched types } }

Discussion:
Roughly according to cc
Some notes: I think this is not worth fixing as it would require hacks deep in the general sequence parser. We should try to still have suggestions; notes that there are special purpose methods for doing that. "Unnecessary" is semantically misleading here as this is a hard error, not a lint.
Change:
<ins> macro_rules! lexes {($($_:tt)*) => {}} lexes!(🐛#); //~ ERROR identifiers cannot contain emoji lexes!(🐛"foo"); lexes!(🐛'q'); lexes!(🐛'q); fn main() {} </ins>

Discussion:
In the 2015 and 2018 editions, the following compiles (with warnings): ` [playground] The is taken as an identifier, although emoji aren't generally permitted in identifiers in any edition. I tested with 1.77.1. I think the underlying problem is that and in distinguish "identifiers" containing emoji (as rather than ), but don't have a way to make that distinction for . [playground]:
Regression from 1.57 to 1.58 (stable to stable). Very likely in , cc Regression from error to pass. Previous error: .
WG-prioritization assigning priority (). label -I-prioritize +P-low
thank you for the detailed report. will fix this.
Change:
unwind_resume_hooked: Cell::new(false), intrinsics: RefCell::new(FnvHashMap()), n_llvm_insns: Cell::new(0), <ins> type_of_depth: Cell::new(0), </ins> trait_cache: RefCell::new(FnvHashMap()), };

Discussion:
Repeating segment:
Note: the type is regular, just not representable (actual non-regular data types make selection overflow, possibly at trans time).
This particular case could be handled in type-checking, but the general case requires some sort of recursion check after the type has been monomorphized.

causes a stack overflow.
This is a stack overflow inside middle::traits::project::normalizeprojectiontype

I've encountered a variant of this bug (or is it another bug? please advise if so and I will post it separately): If I remove the lifetime, the stack overflow no longer occurs.
Seems to be a dupe of
example was fixed in 1.4.

The following program generates a trans-time stack overflow.
Can confirm this is still an issue
This is somewhat distinct from , as it creates an irregular type without selection errors.
actually, not really.

On 3/4/2015 on playpen, the following code: the following error: This may be considered a duplicate of issue , which notes a similar problem with recursive trait bounds. I figured this may be unique given that this involves a recursive associated type on a trait, rather than a recursive trait itself.
cc
This was just rediscovered in the #rust IRC.
The code that that IRC example was simplified from was code that looked reasonably sane (and was quite far removed from simple recursion like this), so trying to come up with an error message instead of a crash would be quite handy.
Change:
#[inline] unsafe fn into_ascii_nocheck(self) -> Vec<Ascii> { <del> mem::transmute(self) </del> <ins> let v = Vec::from_raw_parts(self.len(), self.capacity(), mem::transmute(self.as_ptr())); // We forget `self` to avoid freeing it at the end of the scope // Otherwise, the returned `Vec` would point to freed memory mem::forget(self); v </ins> } }

Discussion:
There are 3 cases of this undefined behaviour in : There is no guarantee that and have the same layout under the new rules. This needs to manually copy over the fields one by one which would compile to the same code as long as a feature like struct randomization wasn't enabled. Since vectors expose , it could be switched to make use of that. However, this is a pervasive issue with in the standard libraries.
I would like to fix this one. However, I don't understand why you would need to use . If we need to copy everything, why don't we do it directly to a ?
the fields of Vec are private, so you can't just use
Change:
self.parent_scope.module = module; } <del> // Handled in `rustc_metadata::{native_libs,link_args}` ItemKind::ForeignMod(..) => {} </del> // These items live in the value namespace. ItemKind::Static(..) => { let res = Res::Def(DefKind::Static, self.r.definitions.local_def_id(item.id));

Discussion:
<short summary of the bugI tried this code: Running on a project that has as its direct or indirect dependency. I expected to see this happen: All packages documented. Instead, this happened: — also fails on . : Does also happen for older nightlies, though I forgot to capture the versions before updating in hope it'd fix the issue. There are more ICE issues pointing at , but none on this line here. Backtrace:
I can confirm that this ICE does not occur on Rust 1.37.0 stable, as shown in This might be a regression that slipped through the stable release somehow.
This still happens on 1.39 stable.
cc
It also does it when documenting a project with on nightly. I had no trouble documenting all deps more than 2 weeks ago though.
This happened on our recent build rust 1.39.0 as well.
cc please triage regressions! If anyone would like to help out here: This is in need of a minimal example that reproduces the issue, as well as a bisection to pinpoint the PR that introduced this regression.
Sorry for not getting to this earlier. I've reduced down to: The is coming from the path inside which is messed up somehow by the macro. Bisecting this pointed to which almost certainly means it was caused by (cc. This is an issue in rustc as well because if you try to use the method from another crate like this for example: rather than the expected new` error since it now produces an ICE: <details<summarybacktrace</summary</detailsAnother interesting case comes from removing the inner module: This compile before but now somehow. Also the regressions in and are a similar but newer regression which I've made a new issue for: .
I guess I'll take a look since it's been a week. Thanks for the minimal code case!
Was this not fixed by ?
I don't know. If so then we're all good?
No, I can confirm there's still an ICE.
Is the nonrustdoc example from still ICEing or is it just the rustdoc issue left?
I'll see what happens.
Similarly to the case in this ICE in rustdoc may mean that a bug or error is silently ignored in rustc. So hiding it like does is not a good idea.
Fixed in
Change:
<ins> // run-rustfix #![allow(dead_code)] struct U <T> { wtf: Option<Box<U<T>>>, x: T, } fn main() { U { wtf: Some(Box(U { //~ ERROR cannot initialize a tuple struct which contains private fields wtf: None, x: (), })), x: () }; } </ins>

Discussion:
Could someone change the bad title? I am not good for english.
Seems like more of a diagnostics issue. is a private constructor, but we're erroring out on type-checking before we realize this. The fix for this specific code is to replace with
Triage: this now has a different, yet still confusing, error:
That error is correct; but either way, the other error you get today is this, which while not ideal, is possibly the best we can do. I guess we could look for a method with a single parameter? But that seems hacky.
It is, but it is a common enough pattern and such a big enhancement in end user experience that I feel it'd be worth it to add it, specially when the ctor is not public. Then, the output should be: Similar output, but not quite the same cause in .
In order to implement this there's a bit of roadblock at the moment. The verification if a struct has a given method is done in , while this error is being emitted in . I believe the error is being bubbled up, but it would have to be delayed on its entirety to the type check step in order to verify wether exists. :-/ You can look for traits that have a given method (), but when I tried it with it returned an empty . We could provide with a generic suggestion about trying out , but I would much rather prefer if we could have some certainty that the method exists instead of potentially misleading the user.
Current output:
The error message seems pretty good... let's close this?
I still think that . Definitely low priority now given the other improvements on the error.
: We still need to look for and suggest it.
Change:
LL |     if let ....3 = 0 {} |            ^^^^^ help: try using the minimum value for the type: `MIN...0.3` <ins> error: `..X` range patterns are not supported --> $DIR/recover-range-pats.rs:139:17 | LL |             let ..$e; |                 ^^ help: try using the minimum value for the type: `MIN..0` ... LL |     mac!(0); |     -------- in this macro invocation error: `...X` range patterns are not supported --> $DIR/recover-range-pats.rs:140:17 | LL |             let ...$e; |                 ^^^ help: try using the minimum value for the type: `MIN...0` ... LL |     mac!(0); |     -------- in this macro invocation error: `..=X` range patterns are not supported --> $DIR/recover-range-pats.rs:142:17 | LL |             let ..=$e; |                 ^^^ help: try using the minimum value for the type: `MIN..=0` ... LL |     mac!(0); |     -------- in this macro invocation error: `X..` range patterns are not supported --> $DIR/recover-range-pats.rs:143:19 | LL |             let $e..; |                   ^^ help: try using the maximum value for the type: `0..MAX` ... LL |     mac!(0); |     -------- in this macro invocation error: `X...` range patterns are not supported --> $DIR/recover-range-pats.rs:144:19 | LL |             let $e...; |                   ^^^ help: try using the maximum value for the type: `0...MAX` ... LL |     mac!(0); |     -------- in this macro invocation error: `X..=` range patterns are not supported --> $DIR/recover-range-pats.rs:146:19 | LL |             let $e..=; |                   ^^^ help: try using the maximum value for the type: `0..=MAX` ... LL |     mac!(0); |     -------- in this macro invocation </ins> error: `...` range patterns are deprecated --> $DIR/recover-range-pats.rs:41:13 |

Discussion:
The CI for started to fail today with this error: It appears as though the compiler doesn't see and only sees as the range expression and then generates this error. The expression is inside a expansion. You can reproduce this by cloning the repo and building it: The build succeeds on the stable channel and much older releases, so this appears to be a regression in the nightly. Here's the version on my windows system, but note that this also fails on linux and macos too:
Regression introduced in
More specifically the bug is in: which is called to see whether what follows is a valid start of a range pattern end expression. This is strange tho... in the case of e.g.: the call to in is used successfully to parse but somehow that doesn't work for . cc
Similarly, with: this does not trigger "error: range patterns are not supported" but it should.
Change:
<ins> #![feature(linkage)] #![feature(stmt_expr_attributes)] #![deny(unused_attributes)] #![allow(dead_code)] #[linkage = "weak"] //~ ERROR attribute should be applied to a function or static type InvalidTy = (); #[linkage = "weak"] //~ ERROR attribute should be applied to a function or static mod invalid_module {} #[linkage = "weak"] //~ ERROR attribute should be applied to a function or static struct F; #[linkage = "weak"] //~ ERROR attribute should be applied to a function or static impl F { #[linkage = "weak"] fn valid(&self) {} } #[linkage = "weak"] fn f() { #[linkage = "weak"] { 1 }; //~^^^^ ERROR attribute should be applied to a function or static } extern "C" { #[linkage = "weak"] static A: *const (); #[linkage = "weak"] fn bar(); } fn main() { let _ = #[linkage = "weak"] (|| 1); //~^^ ERROR attribute should be applied to a function or static } </ins>

Discussion:
I tried this code: I expected to see this happen: compilation failure because of attribute on an item where it makes no sense Instead, this happened: compiled successfully : cc see for where to fix this issue <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim