jiebi/CodeConvo huggingface dataset:
Code change:
<del> //@ known-bug: rust-lang/rust#124563 use std::marker::PhantomData; pub trait Trait {} pub trait Foo { type Trait: Trait; type Bar: Bar; fn foo(&mut self); } pub struct FooImpl<'a, 'b, A: Trait>(PhantomData<&'a &'b A>); impl<'a, 'b, T> Foo for FooImpl<'a, 'b, T> where T: Trait, { type Trait = T; type Bar = BarImpl<'a, 'b, T>; fn foo(&mut self) { self.enter_scope(|ctx| { BarImpl(ctx); }); } } impl<'a, 'b, T> FooImpl<'a, 'b, T> where T: Trait, { fn enter_scope(&mut self, _scope: impl FnOnce(&mut Self)) {} } pub trait Bar { type Foo: Foo; } pub struct BarImpl<'a, 'b, T: Trait>(&'b mut FooImpl<'a, 'b, T>); impl<'a, 'b, T> Bar for BarImpl<'a, 'b, T> where T: Trait, { type Foo = FooImpl<'a, 'b, T>; } </del>

Related discussion:
text: : <details<summary<strongBacktrace</strong</summary<p</p</details
This looks to be a recent regression from cc and is on beta 1.79, but is just in diagnostics.
Code change:
#[plugin_registrar] pub fn registrar() {} //~^ ERROR compiler plugins are experimental <del> //~| HELP add #![feature(plugin_registrar)] to the crate attributes to enable </del> fn main() {}

Related discussion:
text: Steps to reproduce: The output of is: does as suggested by the message, but that fails too (as expected): Proposed fix: in the beta and stable channels (i.e. whenever is forbidden), the message that suggests adding should not be shown. (Clean up the test case with .) CC
Gonna milestone this real quick, as it seems quite important.
I might be able to whip up a quick fix, though I'm not 100% sure about testing it properly ... (I've never actually tried building something for a non-dev release channel before...)
after chatting with it seems like I have a patch, building it now
gonna leave to it
Hello good Rust folks :smile: Before the beta, I used which is in . Is there any way to use this trait during the beta ? I'm not sure how I can get the code to compile. Thanks for any tip / hints you can offer :+1:
Hi Commenting on random unrelated issues is usually not the right thing to do. You should rather open a new issue, or ask on . But to answer your question anyway, that trait only has : … and is stable and can be used on beta. So I’d recommend you copy/paste the trait into your code, or make a function.
Thanks for taking the time to answer. I appreciate it. I don't see how this is unrelated. This is related, since the code I'm talking about used to compile with and the compiler suggests to do that, during the beta period. Thanks for your tip on copying the function :+1: I guess I'll just do that if nothing better is available and change this again when the trait is stable.
This specific issue is about fixing one of the compiler’s error message, not about fixing code that triggers that error. It really helps everyone to keep discussions on topic.
Alright. I understand. I'll make sure to open a new issue or go on StackOverflow next time if appropriate. Thanks again :+1:
This doesn't seem to be properly fixed in the beta channel. I'm still being recommended to add in the errors, and then told it's not available in the beta channel. Rust version: The code I used (snappy example in the docs with the extra addition on the first line:
This happened after Beta release.
Code change:
#[plugin_registrar] pub fn registrar() {} //~^ ERROR compiler plugins are experimental <del> //~| HELP add #![feature(plugin_registrar)] to the crate attributes to enable </del> fn main() {}

Related discussion:
text: We'll see the effect of this patch in 1.0 and afterwards Beta, etc.
Whoops, I thought this made it in before beta. Thanks!
are there plans to release updates to the beta channel within a given 6 weeks cycle? Either this one or in the future.
I'm certain there will be updates; see discussion from last night here:
So how does one fix this error? I'm a new user of the rust library and I can't seem to use the collections library during the beta due to this problem. Given this git issue is a top google result, it would be nice if there were a solution here. Edit: Looks like the solution is to switch to the rust nightly. Is the entire collections library off-limits in the beta?
by design, you have access to the parts of that are re-exported from (and are stable).
Code change:
If you do, Rust has been installed successfully! Congrats! <del> If you don't and you're on Windows, check that Rust is in your %PATH% system variable: `$ echo %PATH%`. If it isn't, run the installer again, select "Change" on the "Change, repair, or remove installation" page and ensure "Add to PATH" is installed on the local hard drive.  If you need to configure your path manually, you can find the Rust executables in a directory like `"C:Program FilesRust stable GNU 1.xbin"`. </del> <ins> If you don't, that probably means that the `PATH` environment variable doesn't include Cargo's binary directory, `~/.cargo/bin` on Unix, or `%USERPROFILE%.cargobin` on Windows. This is the directory where Rust development tools live, and most Rust developers keep it in their `PATH` environment variable, which makes it possible to run `rustc` on the command line. Due to differences in operating systems, command shells, and bugs in installation, you may need to restart your shell, log out of the system, or configure `PATH` manually as appropriate for your operating environment. </ins> Rust does not do its own linking, and so you’ll need to have a linker installed. Doing so will depend on your specific system. For

Related discussion:
text: Specifically at , and recommend for Windows too, right? We've , but in the meantime, the old book should recommend the new recommended toolchain :) If it's too soon to do this because isn't stable enough yet, consider this a reminder issue to make this change once it is :)
wants to wait a bit, and we'd need to then make sure to update the website in sync (see )
Maybe the big red warning "this is beta software" should be removed from the website?
This will be fixed by
Code change:
<ins> // run-pass #![feature(inline_const)] // Makes sure we don't propagate generic instances of `Self: ?Sized` blanket impls. // This is relevant when we have an overlapping impl and builtin dyn instance. // See <https://github.com/rust-lang/rust/pull/114941> for more context. trait Trait { fn foo(&self) -> &'static str; } impl<T: ?Sized> Trait for T { fn foo(&self) -> &'static str { std::any::type_name::<T>() } } fn bar<T: ?Sized>() -> fn(&T) -> &'static str { const { Trait::foo as fn(&T) -> &'static str } // If const prop were to propagate the instance } fn main() { assert_eq!("i32", bar::<dyn Trait>()(&1i32)); } </ins>

Related discussion:
text: <!-- 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: The three printed TypeIds should be identical, as with the behavior in Rust <=1.70 Instead, this happened: switch between rust versions. I could not find reference in the that could explain such behavioral changes.
if my bisection is correct, this surfaced in commit cc (makes sense?)
I do not believe that is the correct PR to point at. Bisecting anything related to MIR opts can be tricky because you need to stabilize the MIR opt pipeline against changes like in that PR which don't actually implement any new behavior, they just change the meaning of MIR opt levels. Try bisecting with ? The above PR just changes the opt level 3 inliner behavior to be the default.
Reproduces since before with
This has to do with the fact that this impl: ... applies even when . Therefore in a polymorphic function like , we're eagerly inlining from that impl even though during monomorphization we'd prefer the built-in candidate instead. This seems problematic.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
_ => unreachable!(), }; <del> write_or_print(&out, ofile); </del> <ins> write_or_print(&out, ofile, tcx.sess); </ins> Ok(()) }

Related discussion:
text: If you , you get a normal error like but if you try to at the same time: rust will panic which is a bit weird. Mayne that panic should be demoted to a regular error? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
To reproduce: `
claim
Code change:
<ins> fn main() { while let 1 = 1 { vec![].last_mut().unwrap() = 3_u8; //~^ ERROR invalid left-hand side of assignment } } </ins>

Related discussion:
text: I was attempting to assign directly to the result of a vector's , which caused this error to fire. That is when I discovered that the help section was telling me to do add an extra let to my while statement, which is not syntactically correct. I tried this code: I expected to see this happen: The code would fail to compile and the help message would tell me to dereference the left side, or at the least give me code that was syntactically correct. Instead, this happened: The could failed to compile, and the help message gave syntactically incorrect code as seen in the backtrace section. <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
This minifies to which reports and are related I think, since this example produces the ICE mentioned there on stable
label +A-diagnostics +D-invalid-suggestion +T-compiler
claim
Code change:
use std::cell::Cell; use std::mem; <del> use std::ops::{Deref, DerefMut}; </del> /// Type lambda application, with a lifetime. #[allow(unused_lifetimes)]

Related discussion:
text: () As you can see, calling directly doesn't instantiate the HRTB (even though it needs to AFAIK) or if it does it doesn't normalize the resulting bound, whereas going through normalizes the instantiated argument types of , while 's definition can be type-checked as-is. EDIT: you can also get an ICE by uncommenting the use in : cc (this might be a duplicate)
Duplicate of (at least the ICE case)? A lot of analysis wad did in the other issue. Maybe it would help. I doubt that, in such cases the associate type do normalize at all. My assumption is: In the case that you marked as "working", it is just delayed the normalization to the later stage. So if the later stage consider this is dead code it is passed and compile, otherwise, when it really need to normalize it, run into ICE. So when called explicitly like , the compiler have no choice but to normalize with . If you instead though, the compiler checked that the requirement to match the argument can in theory fullfill, but the lifetime parameter was not free in the function body so it can consider this is a late bound. So the normalization is not happen right away. Later on, when you add the code in to call , the compiler have to do normalization again, but it is already in codegen (see the backtrace messages) phase, so normalization is unexpected and ICE occurs. Given all that, I guess a proper solution is to add a "late normalization" pass to normalize any postponed normalization like this.
This is a probably a duplicate of and/or ?
closing as duplicate of , which is where I will try to track future instances of this field of ICE.
Code change:
#![feature(plugin, custom_attribute)] #![plugin(lint_for_crate)] #![crate_okay] <ins> #![crate_blue] #![crate_red] #![crate_grey] #![crate_green] </ins> pub fn main() { }

Related discussion:
text: Basically just change this macro to recognize and discard the trailing comma.
That macro declaration is formatted in a weird way. But anyway it should be enough to add to the rule (unless accepting multiple trailing commas is undesired). I could mentor.
How about this:
Out of curiosity, why doesn't rust allow trailing commas after automatically? Does it make it hard to write some macros? Alternately, why isn't there a (optional) repetition specification (e.g. would be 0 or 1 times)?
The extra rule is fine too. It's just more annoying (extra repetition). And there's no technical reason not to support one-or-none patterns as far as I'm aware.
Made a PR :)
Code change:
_ => false, } } <ins> pub fn is_known_rigid(self) -> bool { match self.kind() { Bool | Char | Int(_) | Uint(_) | Float(_) | Adt(_, _) | Foreign(_) | Str | Array(_, _) | Slice(_) | RawPtr(_) | Ref(_, _, _) | FnDef(_, _) | FnPtr(_) | Dynamic(_, _, _) | Closure(_, _) | Generator(_, _, _) | GeneratorWitness(_) | GeneratorWitnessMIR(_, _) | Never | Tuple(_) => true, Error(_) | Infer(_) | Alias(_, _) | Param(_) | Bound(_, _) | Placeholder(_) => false, } } </ins> } /// Extra information about why we ended up with a particular variance.

Related discussion:
text: <!-- 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: The three printed TypeIds should be identical, as with the behavior in Rust <=1.70 Instead, this happened: switch between rust versions. I could not find reference in the that could explain such behavioral changes.
if my bisection is correct, this surfaced in commit cc (makes sense?)
I do not believe that is the correct PR to point at. Bisecting anything related to MIR opts can be tricky because you need to stabilize the MIR opt pipeline against changes like in that PR which don't actually implement any new behavior, they just change the meaning of MIR opt levels. Try bisecting with ? The above PR just changes the opt level 3 inliner behavior to be the default.
Reproduces since before with
This has to do with the fact that this impl: ... applies even when . Therefore in a polymorphic function like , we're eagerly inlining from that impl even though during monomorphization we'd prefer the built-in candidate instead. This seems problematic.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Code change:
<ins> // Copyright 2015 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. //! Dox // @has src/foo/qux/mod.rs.html // @has foo/qux/index.html '//a/@href' '../../src/foo/qux/mod.rs.html' // @has foo/qux/bar/index.html '//a/@href' '../../../src/foo/qux/mod.rs.html' pub mod bar { /// Dox // @has foo/qux/bar/baz/index.html '//a/@href' '../../../../src/foo/qux/mod.rs.html' pub mod baz { /// Dox // @has foo/qux/bar/baz/fn.baz.html '//a/@href' '../../../../src/foo/qux/mod.rs.html' pub fn baz() { } } /// Dox // @has foo/qux/bar/trait.Foobar.html '//a/@href' '../../../src/foo/qux/mod.rs.html' pub trait Foobar { fn dummy(&self) { } } // @has foo/qux/bar/struct.Foo.html '//a/@href' '../../../src/foo/qux/mod.rs.html' pub struct Foo { x: i32, y: u32 } // @has foo/qux/bar/fn.prawns.html '//a/@href' '../../../src/foo/qux/mod.rs.html' pub fn prawns((a, b): (i32, u32), Foo { x, y }: Foo) { } } /// Dox // @has foo/qux/fn.modfn.html '//a/@href' '../../src/foo/qux/mod.rs.html' pub fn modfn() { } </ins>

Related discussion:
text: When visiting a page such as or the link src (for the source code) no longer works. Instead a 404 is returned. This seems to have been broken for several days now.
even before this, many but not all were broken. there may be multiple issues with this symptom.
The links link in the form but it seems like the actual source is being placed in a location in the form For example here's a link from the current docs which will 404: But the following will resolve:
Really annoyed by this. :<
Code change:
.enumerate() .skip(1) // Remove `Self` for `ExistentialPredicate`. .map(|(index, arg)| { <del> if let ty::GenericArgKind::Type(ty) = arg.unpack() { debug!(?ty); if ty == dummy_self { let param = &generics.params[index]; missing_type_params.push(param.name); tcx.ty_error().into() } else if ty.walk().any(|arg| arg == dummy_self.into()) { references_self = true; tcx.ty_error().into() } else { arg } } else { arg </del> <ins> if arg == dummy_self.into() { let param = &generics.params[index]; missing_type_params.push(param.name); return tcx.ty_error().into(); } else if arg.walk().any(|arg| arg == dummy_self.into()) { references_self = true; return tcx.ty_error().into(); </ins> } <ins> arg </ins> }) .collect(); let substs = tcx.intern_substs(&substs[..]);

Related discussion:
text: <!-- 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
This was likely introduced in (CC rustc 1.65 nightly 2022-08-12 emits the following:
Code change:
// of  the function signature. In our example, the GAT in the return // type is `<Self as LendingIterator>::Item<'a>`, so 'a and Self are arguments. let (regions, types) = <del> GATSubstCollector::visit(trait_item.def_id.to_def_id(), sig.output()); </del> <ins> GATSubstCollector::visit(tcx, trait_item.def_id.to_def_id(), sig.output()); </ins> // If both regions and types are empty, then this GAT isn't in the // return type, and we shouldn't try to do clause analysis

Related discussion:
text: <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Slightly minimized:
I understand the issue here, and have a solution but it might not be optimal. claim
Code change:
/// Parses the fields of a struct-like pattern. fn parse_pat_fields(&mut self) -> PResult<'a, (ThinVec<PatField>, PatFieldsRest)> { <del> let mut fields = ThinVec::new(); </del> <ins> let mut fields: ThinVec<PatField> = ThinVec::new(); </ins> let mut etc = PatFieldsRest::None; let mut ate_comma = true; let mut delayed_err: Option<Diag<'a>> = None;

Related discussion:
text: This erroneous code: Produces this error message It would be better if instead it produced an error message like this: Tried the code in these Rust versions and they all produced the same error message: 1.37.0 stable1.45.0 stable1.46.0-beta.1 (2020-07-15 )1.47.0-nightly (2020-07-22 ) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This shouldn't be too hard. This comes from the parser, specifically the code that parses a pattern, which is one of functions. Somewhere there is the code to parse a struct pattern. I assume the error above happens when it successfully parses a struct field and then expects a comma or closing brace. To fix it you'd have to check for and report a better error message.
claim
Code change:
```text #[cfg(all(target_os = "wasi", target_env = "p2"))] ``` <ins> ## Enabled WebAssembly features The default set of WebAssembly features enabled for compilation is currently the same as [`wasm32-unknown-unknown`](./wasm32-unknown-unknown.md). See the documentation there for more information. </ins>

Related discussion:
text: This can be replicated with a minimal : Compile it to WASM with Then, check if the generated WASM uses reference types: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: (and previous stable rust versions) On those versions, compiling the above and then running with doesn't fail. <!-- Provide the version you are using that has the regression. --: <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged -- modify labels: +regression-from-stable-to-nightly -regression-untriaged This seems to have been caused by The compatibility note there says: However, the generated code seems to be indeed affected by default. Interestingly, reference types seem to be used unnecessarily, as using to turn the generated into wat and then to turn it back into wasm removes the reference types. As-is, this breaks compatibility with the WebAssembly 1.0 spec.
cc Looks like this causes issues in practice and we might want to do after all?
WG-prioritization assigning priority (). label -I-prioritize +P-high
I was unable to confirm the presence of any reference type instructions in the generated Wasm, even though I got the same error pointing towards a that looks perfectly valid to me. Interestingly enough, doing the back and forth conversion with and remove the issue, even though the output of both files is exactly the same, apart from the missing debug information. I'm assuming that this is another example of a tool making use of the , so this was already anticipated. Unfortunately (?) this isn't the first time LLVM has enabled features by default, in the past they even did affect code generation. From what I've read in the various WebAssembly specification groups, this was always intended. In conclusion, I agree this is a form of breakage, it seems to be intended, I believe if Rust wants to do anything about it the solution needs to a bit more comprehensive. E.g. actually disable all target features by default (I don't know if this is feasible with LLVM, would need research). See and .
I just spend some time digging into this error message that spits out.