jiebi/CodeConvo huggingface dataset:
Change:
Successor of and . This code: Gives this error message (on nightly): It'd be great if this could work so that you can implement a trait differently for different values of type parameters. cc who suggested to open a new issue for this.
background: his error was introduced in as the previous state was unsound, see
With this test is now working as expected. Marking as .
if I try this: I get this error: Using the nightly from playground
you need full for this, we should probably add a note here which recommends using and here.
alright that works. I'll file a PR

Discussion:
<ins> // run-pass #![feature(const_evaluatable_checked)] #![feature(const_generics)] #![allow(incomplete_features)] trait Foo {} impl<const N: usize> Foo for [(); N] where Self: FooImpl<{ N == 0 }> {} trait FooImpl<const IS_ZERO: bool> {} impl FooImpl<{ 0u8 == 0u8 }> for [(); 0] {} impl<const N: usize> FooImpl<{ 0u8 != 0u8 }> for [(); N] {} fn foo<T: Foo>(_v: T) {} fn main() { foo([]); foo([()]); } </ins>
Change:
Taken from this internals thread: A module named is shadowed leading to misleading error messages. was reserved as a built-in crate name in 2018 edition, but the error message does not indicate this. I tried this code: Above code compiled with This is expected to indicated that is a reserved crate name. Instead, the following error is reported: : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Error: Parsing assign command in failed: ...'tbot claim' ' ?'... Please let know if you're having trouble with this bot.
claim
It's not forbidden as a module name, this obviously works: I think the confusion arises from that fact that this works without : But those are uniform imports (or at least I think that's what they're called), and only resolve to the surrounding scope if unambiguous (which it is for due to the. I'm guessing the right fix here is to add more information to the error suggesting that if the intention wasn't to refer to a crate, or etc. should/can be used explicitly. (EDIT: I went to the internals thread to reply, and it's from March 2019 apparently, and also was mentioned there, but I guess the fact that the name is perfectly fine outside of wasn't brought up) cc
I believe the "fix" was mentioned in a reddit thread linking to the internals thread, but I forgot to mention it. I will reword the issue as it is misworded, as you pointed out. Lastly, what you suggested for a fix lines up with what I was expecting. Also, now you know how deep my backlog of todo items is.

Discussion:
extern_prelude.insert(Ident::with_dummy_span(sym::core), Default::default()); if !session.contains_name(&krate.attrs, sym::no_std) { extern_prelude.insert(Ident::with_dummy_span(sym::std), Default::default()); <del> if session.rust_2018() { extern_prelude.insert(Ident::with_dummy_span(sym::meta), Default::default()); } </del> } }

<del> // edition:2018 // Tests that `meta` is allowed, even if the crate doesn't exist // yet (i.e., it causes a different error than `not-allowed.rs`). use meta; //~ ERROR can't find crate for `meta` fn main() {} </del>

<del> error[E0463]: can't find crate for `meta` --> $DIR/meta.rs:5:5 | LL | use meta; |     ^^^^ can't find crate error: aborting due to previous error For more information about this error, try `rustc --explain E0463`. </del>
Change:
<!-- 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. --Saving a Hello World program as UTF-16: and trying to compile it causes about as many errors as there are characters in the file complaining of . Instead, using some heuristics to determine that the file is saved as UTF16 and printing a more helpful error message would be much friendlier to new users who are most likely to run into this issue. <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
There's still a question. Should throw an error and exit, or read the file using UTF 16?
I do not think rustc should parse the file as UTF-16, as this would introduce an ambiguity. I opened this issue only to address the poor UX of the current error messages.
release-assignment This seems more complicated than expected, because I dont know any reliable way to check if the file is utf-16.
Maybe add a help message when output error "unknown start of token: u{0}".

Discussion:
// tokens like `<<` from `rustc_lexer`, and then add fancier error recovery to it, // as there will be less overall work to do this way. let token = unicode_chars::check_for_substitution(self, start, c, &mut err); <ins> if c == 'x00' { err.help("source files must contain UTF-8 encoded text, unexpected null bytes might occur when a different encoding is used"); } </ins> err.emit(); token? }
Change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --produces an ICE for the code given below. This code should produce an error (the implementation is missing associated items). (UPDATED: Here's MCVE: ) <!-- 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. --: Error also occurs on beta and nightly. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Thanks! Further minimized:
Assigning as and removing .
Don't know the cause yet, but if you remove the keyword or the operator, then you get this error: My hunch is that somehow, lacking those items, the type of is coming up with something that doesn't implement the expected traits -- I would bet that we are getting an , based on some of the output at the end. Perhaps some of the logic in MIR is failing as a result. The actual ICE location though isn't that illuminating:
I did some digging here. The source of the panic is here, during HAIR construction: In this case, the binding below is of the error type (meaning type check for it failed). By replacing the binding with `` we prevent a local from being created for it, which means that when we try to generate code that reads the local we get a panic . I'm not sure what the correct fix is here. Replacing the binding with was done to prevent other ICEs, but we can't generate valid MIR without the local info. More fundamentally: We're building MIR during typeck because this is an async fn. In the past we probably never would have gotten to this stage. Backtrace: <details</details

Discussion:
fn lower_pattern_unadjusted(&mut self, pat: &'tcx hir::Pat<'tcx>) -> Pat<'tcx> { let mut ty = self.typeck_results.node_type(pat.hir_id); <del> if let ty::Error(_) = ty.kind { // Avoid ICEs (e.g., #50577 and #50585). return Pat { span: pat.span, ty, kind: Box::new(PatKind::Wild) }; } </del> let kind = match pat.kind { hir::PatKind::Wild => PatKind::Wild,

<ins> // edition:2018 use std::convert::{TryFrom, TryInto}; use std::io; pub struct MyStream; pub struct OtherStream; pub async fn connect() -> io::Result<MyStream> { let stream: MyStream = OtherStream.try_into()?; Ok(stream) } impl TryFrom<OtherStream> for MyStream {} //~^ ERROR: missing fn main() {} </ins>

<ins> error[E0046]: not all trait items implemented, missing: `Error`, `try_from` --> $DIR/issue-74047.rs:14:1 | LL | impl TryFrom<OtherStream> for MyStream {} | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ missing `Error`, `try_from` in implementation | = help: implement the missing item: `type Error = Type;` = help: implement the missing item: `fn try_from(_: T) -> std::result::Result<Self, <Self as std::convert::TryFrom<T>>::Error> { todo!() }` error: aborting due to previous error For more information about this error, try `rustc --explain E0046`. </ins>
Change:
<!-- 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: compilation failure Instead, this happened: Compiles, outputs "0" <!-- 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. --: Also: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Should be a easy fix. claim

Discussion:
| sym::u32 | sym::i64 | sym::u64 <ins> | sym::i128 | sym::u128 </ins> | sym::isize | sym::usize => { int_reprs += 1;

<ins> #![allow(dead_code)] #[repr(i128)] //~ ERROR: attribute should be applied to enum struct Foo; #[repr(u128)] //~ ERROR: attribute should be applied to enum struct Bar; fn main() {} </ins>

<ins> error[E0517]: attribute should be applied to enum --> $DIR/issue-74082.rs:3:8 | LL | #[repr(i128)] |        ^^^^ LL | struct Foo; | ----------- not an enum error[E0517]: attribute should be applied to enum --> $DIR/issue-74082.rs:6:8 | LL | #[repr(u128)] |        ^^^^ LL | struct Bar; | ----------- not an enum error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0517`. </ins>
Change:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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. --: Also occurs on nightly at <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Semicolon is not the main problem here. Standalone semicolons are allowed as items inside function body. Second function definition would be OK if not for the extern "C" block — AFAIK only function declarations are allowed there, so is not valid syntax.
Prioritized as as per .7B.3B.60)
claim
A possibly clearer repro:
glacier ""
The previous issue has been fixed, let's try again (sorry for the noise!). glacier ""

Discussion:
use rustc_ast::attr; use rustc_ast::node_id::NodeMap; use rustc_ast::ptr::P; <del> use rustc_ast::visit::{self, AssocCtxt, Visitor}; </del> <ins> use rustc_ast::visit::{self, AssocCtxt, FnCtxt, FnKind, Visitor}; </ins> use rustc_data_structures::fx::FxHashSet; use rustc_errors::struct_span_err; use rustc_hir as hir;

} } <ins> fn visit_fn(&mut self, fk: FnKind<'a>, sp: Span, _: NodeId) { match fk { FnKind::Fn(FnCtxt::Foreign, _, sig, _, _) => { self.visit_fn_header(&sig.header); visit::walk_fn_decl(self, &sig.decl); // Don't visit the foreign function body even if it has one, since lowering the // body would have no meaning and will have already been caught as a parse error. } _ => visit::walk_fn(self, fk, sp), } } </ins> fn visit_assoc_item(&mut self, item: &'a AssocItem, ctxt: AssocCtxt) { self.lctx.with_hir_id_owner(item.id, |lctx| match ctxt { AssocCtxt::Trait => {

<ins> // Previously this ICE'd because `fn g()` would be lowered, but the block associated with `fn f()` // wasn't. // compile-flags: --crate-type=lib extern "C" { fn f() { //~^ incorrect function inside `extern` block fn g() {} } } </ins>

<ins> error: incorrect function inside `extern` block --> $DIR/issue-74120-lowering-of-ffi-block-bodies.rs:7:8 | LL |   extern "C" { |   ---------- `extern` blocks define existing foreign functions and functions inside of them cannot have a body LL |       fn f() { |  ________^___- | |        | | |        cannot have a body LL | | LL | |         fn g() {} LL | |     } | |_____- help: remove the invalid body: `;` | = help: you might have meant to write a function accessible through FFI, which can be done by writing `extern fn` outside of the `extern` block = note: for more information, visit https://doc.rust-lang.org/std/keyword.extern.html error: aborting due to previous error </ins>
Change:
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.

Discussion:
<del> Subproject commit fd8101247749c5be6850d5cb5096f01a1867e5ba </del> <ins> Subproject commit eb5ff1791be706d173b4f4c29e9c0529b4235c0e </ins>
Change:
With merged (current nightly, e.g. ) , the following code now produces a warning: This triggers : But rustdoc never actually generates any links to , because it wasn't run with . In my opinion it shouldn't emit warning in this case, because documenting the internals can be very useful to contributors or even future me when is used. There has already been some discussion at the end of , which is where I asked first about whether this change was intentional.
modify labels: T-rustdoc A-intra-doc-links
Assuming the consensus is that rustdoc shouldn't warn in this case, would an additional check against the 's visibility be correct? Like: That certainly gets rid of the warning in my case, but I'm unsure about the other variants of and all the other kinds of things can refer to.
That looks reasonable to me. Could you make a PR with that change and a few test cases?
Wouldn't the check like I changed it then only catch cases like this: But that already triggers anyway:
the link is entirely separate from the type of the field. You could have in which case there would be no error but the warning should still be generated.
Ah, yes of course, thanks for pointing that out :) I'll open a PR then.

Discussion:
let hir_id = self.cx.tcx.hir().as_local_hir_id(local); if !self.cx.tcx.privacy_access_levels(LOCAL_CRATE).is_exported(hir_id) <ins> && (item.visibility == Visibility::Public) </ins> && !self.cx.render_options.document_private { let item_name = item.name.as_deref().unwrap_or("<unknown>");

<ins> warning: `[PrivateType]` public documentation for `public_item` links to a private item --> $DIR/issue-74134.rs:19:10 | LL |     /// [`PrivateType`] |          ^^^^^^^^^^^^^ this item is private | = note: `#[warn(intra_doc_link_resolution_failure)]` on by default warning: 1 warning emitted </ins>

<ins> // revisions: public private // [private]compile-flags: --document-private-items // check-pass // There are 4 cases here: // 1. public item  -> public type:  no warning // 2. public item  -> private type: warning, if --document-private-items is not passed // 3. private item -> public type:  no warning // 4. private item -> private type: no warning // All 4 cases are tested with and without --document-private-items. // // Case 4 without --document-private-items is the one described in issue #74134. struct PrivateType; pub struct PublicType; pub struct Public { /// [`PublicType`] /// [`PrivateType`] //[public]~^ WARNING public documentation for `public_item` links to a private pub public_item: u32, /// [`PublicType`] /// [`PrivateType`] private_item: u32, } // The following cases are identical to the ones above, except that they are in a private // module. Thus they all fall into cases 3 and 4 and should not produce a warning. mod private { pub struct Public { /// [`super::PublicType`] /// [`super::PrivateType`] pub public_item: u32, /// [`super::PublicType`] /// [`super::PrivateType`] private_item: u32, } } </ins>
Change:
: <details<summary<strongBacktrace</strong</summary<p</p</detailssearched nightlies: from nightly-2019-10-03 to nightly-2020-07-05 regressed nightly: nightly-2020-02-16 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
Minified, It seems possible to ICE on stable, though I'm not sure if it counts? <details<summaryStable error</summary</details
The ICE is fixed in the latest nightly, marking as .

Discussion:
<ins> // compile-flags: -Zmir-opt-level=3 // run-pass #![feature(const_generics)] #![allow(incomplete_features)] fn main() { fn foo<const N: usize>() -> [u8; N] { [0; N] } let _x = foo::<1>(); } </ins>

<ins> // check-pass fn main() { let array = [0x42u8; 10]; for b in &array { let lo = b & 0xf; let hi = (b >> 4) & 0xf; } } </ins>

<ins> // check-pass #![allow(unreachable_patterns)] fn main() { const CONST: &[Option<()>; 1] = &[Some(())]; match &[Some(())] { &[None] => {} CONST => {} &[Some(())] => {} } } </ins>

<ins> const F: &'static dyn PartialEq<u32> = &7u32; fn main() { let a: &dyn PartialEq<u32> = &7u32; match a { F => panic!(), //~ ERROR: `&dyn PartialEq<u32>` cannot be used in patterns } } </ins>

<ins> error: `&dyn PartialEq<u32>` cannot be used in patterns --> $DIR/issue-72565.rs:6:9 | LL |         F => panic!(), |         ^ error: aborting due to previous error </ins>

<ins> #![feature(type_alias_impl_trait)] trait Allocator { type Buffer; } struct DefaultAllocator; impl<T> Allocator for DefaultAllocator { //~^ ERROR: the type parameter `T` is not constrained type Buffer = (); } type A = impl Fn(<DefaultAllocator as Allocator>::Buffer); fn foo() -> A { |_| () } fn main() {} </ins>

<ins> error[E0207]: the type parameter `T` is not constrained by the impl trait, self type, or predicates --> $DIR/issue-74244.rs:9:6 | LL | impl<T> Allocator for DefaultAllocator { |      ^ unconstrained type parameter error: aborting due to previous error For more information about this error, try `rustc --explain E0207`. </ins>
Change:
The unit struct via , so it's the cleanest way to do this. This could potentially be a lint warning, with a suggestion.
A lint for empty drops is probably unnecessary, I wouldn't imagine that would be a common idiom once NonCopyable is well-known.
I only see one of these, in libsyntax.

Discussion:
quote_depth: @mut 0, obsolete_set: @mut HashSet::new(), mod_path_stack: @mut ~[], <del> open_braces: @mut ~[] </del> <ins> open_braces: @mut ~[], non_copyable: util::NonCopyable </ins> } }

/// Used to determine the path to externally loaded source files mod_path_stack: @mut ~[@str], /// Stack of spans of open delimiters. Used for error message. <del> open_braces: @mut ~[Span] } #[unsafe_destructor] impl Drop for Parser { </del> <ins> open_braces: @mut ~[Span], </ins> /* do not copy the parser; its state is tied to outside state */ <del> fn drop(&mut self) {} </del> <ins> priv non_copyable: util::NonCopyable </ins> } fn is_plain_ident_or_underscore(t: &token::Token) -> bool {
Change:
results in
Could this be a duplicate of ?
:+1: This probably has the same fix. I do think that the issues are different enough to keep this one open though

Discussion:
use rustc_hir::def_id::{DefId, CRATE_DEF_INDEX, LOCAL_CRATE}; use rustc_hir::PrimTy; use rustc_session::config::nightly_options; <ins> use rustc_session::parse::feature_err; </ins> use rustc_span::hygiene::MacroKind; use rustc_span::symbol::{kw, sym, Ident, Symbol}; use rustc_span::{BytePos, Span, DUMMY_SP};

_ => {} } } <ins> /// Non-static lifetimes are prohibited in anonymous constants under `min_const_generics` so /// this function will emit an error if `min_const_generics` is enabled, the body identified by /// `body_id` is an anonymous constant and `lifetime_ref` is non-static. crate fn maybe_emit_forbidden_non_static_lifetime_error( &self, body_id: hir::BodyId, lifetime_ref: &'tcx hir::Lifetime, ) { let is_anon_const = matches!( self.tcx.def_kind(self.tcx.hir().body_owner_def_id(body_id)), hir::def::DefKind::AnonConst ); let is_allowed_lifetime = matches!( lifetime_ref.name, hir::LifetimeName::Implicit | hir::LifetimeName::Static | hir::LifetimeName::Underscore ); if self.tcx.features().min_const_generics && is_anon_const && !is_allowed_lifetime { feature_err( &self.tcx.sess.parse_sess, sym::const_generics, lifetime_ref.span, "a non-static lifetime is not allowed in a `const`", ) .emit(); } } </ins> }

let result = loop { match *scope { Scope::Body { id, s } => { <ins> // Non-static lifetimes are prohibited in anonymous constants under // `min_const_generics`. self.maybe_emit_forbidden_non_static_lifetime_error(id, lifetime_ref); </ins> outermost_body = Some(id); scope = s; }

<ins> #![feature(min_const_generics)] // This test checks that non-static lifetimes are prohibited under `min_const_generics`. It // currently emits an error with `min_const_generics`. This will ICE under `const_generics`. fn test<const N: usize>() {} fn issue_75323_and_74447_1<'a>() -> &'a () { test::<{ let _: &'a (); 3 },>(); //~^ ERROR a non-static lifetime is not allowed in a `const` &() } fn issue_75323_and_74447_2() { test::<{ let _: &(); 3 },>(); } fn issue_75323_and_74447_3() { test::<{ let _: &'static (); 3 },>(); } fn issue_73375<'a>() { [(); (|_: &'a u8| (), 0).1]; //~^ ERROR a non-static lifetime is not allowed in a `const` } fn main() {} </ins>

<ins> error[E0658]: a non-static lifetime is not allowed in a `const` --> $DIR/forbid-non-static-lifetimes.rs:9:22 | LL |     test::<{ let _: &'a (); 3 },>(); |                      ^^ | = note: see issue #44580 <https://github.com/rust-lang/rust/issues/44580> for more information = help: add `#![feature(const_generics)]` to the crate attributes to enable error[E0658]: a non-static lifetime is not allowed in a `const` --> $DIR/forbid-non-static-lifetimes.rs:23:16 | LL |     [(); (|_: &'a u8| (), 0).1]; |                ^^ | = note: see issue #44580 <https://github.com/rust-lang/rust/issues/44580> for more information = help: add `#![feature(const_generics)]` to the crate attributes to enable error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0658`. </ins>
Change:
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.
I don't think we can resolve this until is fixed, as we can't build a libstd anymore :(
However, that cannot be the only problem -- Miri also fails to build in-tree: any idea why those might be missing?
is an optional dependency of libstd, and Miri does not enable that option. Looks like the backtrace code incorrectly expects it to be present anyway?
Ah this is my mistake, I didn't check that libstd still compiled without the dependency. I believe that unconditionally depending on is indeed the right thing to do. I can send a PR for this tomorrow if no one else gets to it.
Just please make sure to also include it in rust-src then :)
I'm hoping this will be fixed by
You can test that via 'x.py test --stage 0 src/tools/miri'
That indeed solved the libstd build issue, at least for in-tree builds. Now the problem is Previously, disabling the feature meant we did not have to do anything. Now it seems like some C FFI () is mandatory? That's odd though, elsewhere said this is now Rust-only.
Interestingly, is only called on a double-panic.
should help (and that's way easier than finding all the methods we have to stub, in particular on Windows).
Backtraces are unconditionally generated on double panics, and some reshuffling of the crate itself probably meant that happened to go to the noop unwinder before and now it went to the libunwind unwinder. In any case should fix that issue.

Discussion:
<del> Subproject commit 8f89434446f72f27f8145d8bbc1a302c6ef29d1e </del> <ins> Subproject commit 5965cf5fc17affc84c11dc9972ae8f4dc2c32db1 </ins>