jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // edition:2018 struct S { foo: usize, } impl S { async fn bar(&self) { //~ HELP consider changing this to be a mutable reference //~| SUGGESTION &mut self self.foo += 1; //~ ERROR cannot assign to `self.foo`, which is behind a `&` reference [E0594] } } fn main() { S { foo: 1 }.bar(); } </ins>

Related discussion:
text: Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should look like: <!-- If the problem is not self-explanatory, please provide a rationale for the change. --is not a valid argument; it needs to be either or . For some reason this problem only happens when the function is async.
This is the same diagnostic you get when mutably dereferencing let-bindings that are : So it seems like this has to do with the fact that ast_lowering emits a binding when desugaring. I wonder if we can get the name of the variable when emitting this diagnostic, and special-case when it .
Another (possibly related?) bug: doesn't have the suggestion if it's in an async block:
Same with closures. I would probably classify that as a separate bug, since the original bug has to do specifically with desugaring, and the latter has to do with closure/generator captures.
Thanks for the report and getting a PR up so quickly! label +AsyncAwait-Triaged +AsyncAwait-Polish
Another similar error, not related to async this time: isn't valid Rust.
Code change:
<ins> // check-pass struct Foo { foo: Option<&'static Foo> } static FOO: Foo = Foo { foo: Some(&FOO), }; fn main() {} </ins>

Related discussion:
text: Let's tying to compile this code.This code compiled ok on stable and on nightly-2019-06-17 (for example at rust play site) But in current rustc 1.37.0-nightly ( 2019-06-26) compilation fails with message:
Bisected to: Ok Fail ...
I bisected to , which is also part of the range identified. I get build failures when I try to bisect further into the commits of that PR. cc
Hmm curious, we do have tests for such situations. I'll investigate, but it'll drop into beta today. It's probably an easy fix
Today? Beta cutoff is on Tuesday.
Not this time I believe
Beta cutoff is 2019-06-29 https://rust-
triage: P-high, remove nomination, assign to
FYI, Oli is on vacation for 2 weeks.
Should this be marked regression-from-stable-to-beta now?
Code change:
<ins> // Copyright 2014 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. pub fn foo(params: Option<&[&str]>) -> uint { params.unwrap().head().unwrap().len() } fn main() { let name = "Foo"; let msg = foo(Some(&[name.as_slice()])); //~^ ERROR mismatched types: expected `core::option::Option<&[&str]>` assert_eq!(msg, 3); } </ins>

Related discussion:
text: Here is the error Here is the code that generates the error My system is x86_64 archlinux. The rust compiler version is Let me know if you guys need anything else. (The code is really short so it shouldn't be hard to just type it in to duplicate the bug)
It only needs one line for me
Workaround (in the sense that the compiler no longer ICE's): I think there is some unfortunate interaction here with the way we attempt to infer which kind of numeric literals are in the array (, , etc) and other code not being prepared to handle the that results when you don't have that information available.
This is almost certainly a duplicate of (but maybe the integer inference codepath is slightly different?).
This also causes the same ICE -
Similarly:
Looks like it's been fixed.
Code change:
<ins> // Copyright 2014 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. pub fn foo(params: Option<&[&str]>) -> uint { params.unwrap().head().unwrap().len() } fn main() { let name = "Foo"; let msg = foo(Some(&[name.as_slice()])); //~^ ERROR mismatched types: expected `core::option::Option<&[&str]>` assert_eq!(msg, 3); } </ins>

Related discussion:
text: Swapping the order of the branches compiles fine. cc
Just checked: this fails with a normal closure too, not just a proc.
Compiles fine now but potentially needs a test.
Code change:
<ins> // Copyright 2014 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. pub fn foo(params: Option<&[&str]>) -> uint { params.unwrap().head().unwrap().len() } fn main() { let name = "Foo"; let msg = foo(Some(&[name.as_slice()])); //~^ ERROR mismatched types: expected `core::option::Option<&[&str]>` assert_eq!(msg, 3); } </ins>

Related discussion:
text: Versions: Code to reproduce the ICE: Compilation output:
Seems to be fine now but potentially needs a test.
Nope, still failing. An updated example:
That code example fails to compile, but it's because the function signature for is wrong. It should be: When you make that change and make the struct fields public, the code compiles fine. Without the change I also didn't see any internal compiler errors. Rust Version: 0.12.0-pre-nightly, , Linux x8664
Yeah, I think this can be closed.
Flagging as needstest (not sure if one is checked in already)
Code change:
<ins> // Copyright 2014 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. pub fn foo(params: Option<&[&str]>) -> uint { params.unwrap().head().unwrap().len() } fn main() { let name = "Foo"; let msg = foo(Some(&[name.as_slice()])); //~^ ERROR mismatched types: expected `core::option::Option<&[&str]>` assert_eq!(msg, 3); } </ins>

Related discussion:
text: It gives
cc
Looks like it no longer causes an ICE.
I agree, it is fixed, I close it.
Code change:
fn ty_generics<'a,'tcx>(ccx: &CrateCtxt<'a,'tcx>, space: ParamSpace, ast_generics: &hir::Generics, <del> base_generics: &ty::Generics<'tcx>) </del> <ins> base_generics: &ty::Generics<'tcx>, allow_defaults: bool) </ins> -> ty::Generics<'tcx> { let tcx = ccx.tcx;

Related discussion:
text: If I understand correctly, type parameter defaults have no effect in the block . Just like in PR , this should have a warning and then an error. Example cc
Argh, I guess I failed to cover those?
Nominating for triage.
triage: P-high
Code change:
<del> Subproject commit 81e59e6b92cf1729aabbbbf09b81a81a03775d64 </del> <ins> Subproject commit dadcbebfbd017aac2358cf652a4bd71a91694edc </ins>

Related discussion:
text: 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!
Ah, I see now. That PR removes splats (hopefully temporarily), and unfortunately, because of how natural it is, a few tests for Miri already use the splatting syntax. Yes, I can clean this up.
Yeah I just tried and was happy to see it work. :)
Fix happening on the Miri side in (it was so easy I just quickly did it)
Code change:
// Output the documentation for each function individually if !required.is_empty() { write!(w, " <del> <h2 id='required-methods'>Required Methods</h2> </del> <ins> <h2 id='required-methods' class='section-header'> <a href='#required-methods'>Required Methods</a> </h2> </ins> <div class='methods'> ")?; for m in &required {

Related discussion:
text: A page like has many things that could be useful to link to. These should be possible to link to by clicking on: [x] The header [x] 's on a page. [x] at the top On it's hit or miss: [x] Examples [x] Associated Types [x] Required Methods [x] Implementors On [x] Provided Methods I don't have any big use cases but when I want to link to these for something like this bug I can't link to any specific line. I gotta say go to vec page, scroll 75% to bottom. Squint hard to see it.
Just ran into this today; I'd really like to have links from the impls in the Implementors section to the source containing the impl.
Triage: we always need more links....
Update: Headers written in docs and (most) auto-generated headers are either fully hyperlinked or have a "section marker" symbol that shows up on hover. Major auto-generated page headers have links in the top of the sidebar of the page. Impl blocks do not have hyperlinks (yet); that's
Since got merged and closed out , that was the last major request on this issue, so i'll close this out. If you think of something else that needs a hyperlinked header, feel free to open a new issue or reopen this one.
Code change:
<ins> error[E0107]: this associated function takes 0 generic arguments but 1 generic argument was supplied --> $DIR/issue-101421.rs:10:8 | LL |     ().f::<()>(()); |        ^------ help: remove these generics |        | |        expected 0 generic arguments | note: associated function defined here, with 0 generic parameters --> $DIR/issue-101421.rs:2:8 | LL |     fn f(&self, _: ()); |        ^ error: aborting due to previous error For more information about this error, try `rustc --explain E0107`. </ins>

Related discussion:
text: Repros on the /current nightly. But works (gives an error about mismatched number of generic arguments) on stable and beta. s/o to for the minimal example. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
label regression-from-stable-to-nightly
Regressed in (nightly-2022-09-02), presumably , though seems to have already made the connection to that PR anyways :-)
Code change:
<ins> // revisions: cfail #![feature(const_generics, const_evaluatable_checked)] #![allow(incomplete_features)] // regression test for #79251 struct Node<const D: usize> where SmallVec<{ D * 2 }>: , { keys: SmallVec<{ D * 2 }>, } impl<const D: usize> Node<D> where SmallVec<{ D * 2 }>: , { fn new() -> Self { let mut node = Node::new(); node.keys.some_function(); //~^ error: no method named node } } struct SmallVec<const D: usize> {} fn main() {} </ins>

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. --I'm creating this issue mainly because it seems to be a different one than the ones listed in <!-- 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
What command are you running? I tried this code , but I encountered an error that doesn't have a method.
how strange, for me just causes the ice and it doesn't even come to notice that the function is missing. I just ran , and with the newest rustc () I still get the same error as above (in a new cargo project with the code copied from the playground link above).
Just ran again today and still get an ICE. Made the example a bit smaller: Output of (build also fails with the same message): Considering the rustc versions it should be the same that is currently on the playground, however there it does not cause an ICE. Maybe someone could try to reproduce this in a local environment?
can reproduce this locally, not sure why it doesn't ICE on the playground
cc -- it ICEs locally, but not on the playground
Try with ?
That indeed removes the ICE, let me just check which one of the options it is. Adding to the (or profile.release in release mode) section causes the ice to disappear.
That's even weirder. Seems like this is partly an incr-comp bug then.
Note that the ICE occurs in the incr-comp hasher (ICH): So this seems to be an incr-comp bug.
Reposting : So I removed .
Code change:
<ins> // revisions: cfail #![feature(const_generics, const_evaluatable_checked)] #![allow(incomplete_features)] // regression test for #79251 struct Node<const D: usize> where SmallVec<{ D * 2 }>: , { keys: SmallVec<{ D * 2 }>, } impl<const D: usize> Node<D> where SmallVec<{ D * 2 }>: , { fn new() -> Self { let mut node = Node::new(); node.keys.some_function(); //~^ error: no method named node } } struct SmallVec<const D: usize> {} fn main() {} </ins>

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<details<summary<strongQuery Stack</strong</summary<p</p</details
modify labels to +requires-nightly
The following snippet gives the same ICE. The types are intentionally wrong. <details<summary<strongBacktrace</strong</summary<p</p</details<details<summary<strongQuery Stack</strong</summary<p</p</details
Triage: This is now fixed on the recent nightly, marking as E-needs-test.
Code change:
<ins> // Copyright 2014 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. pub mod two_tuple { trait T {} struct P<'a>(&'a T + 'a, &'a T + 'a); pub fn f<'a>(car: &'a T, cdr: &'a T) -> P<'a> { P(car, cdr) } } pub mod two_fields { trait T {} struct P<'a> { car: &'a T + 'a, cdr: &'a T + 'a } pub fn f<'a>(car: &'a T, cdr: &'a T) -> P<'a> { P{ car: car, cdr: cdr } } } fn main() {} </ins>

Related discussion:
text: Here is the error Here is the code that generates the error My system is x86_64 archlinux. The rust compiler version is Let me know if you guys need anything else. (The code is really short so it shouldn't be hard to just type it in to duplicate the bug)
It only needs one line for me
Workaround (in the sense that the compiler no longer ICE's): I think there is some unfortunate interaction here with the way we attempt to infer which kind of numeric literals are in the array (, , etc) and other code not being prepared to handle the that results when you don't have that information available.
This is almost certainly a duplicate of (but maybe the integer inference codepath is slightly different?).
This also causes the same ICE -
Similarly:
Looks like it's been fixed.
Code change:
<ins> // Copyright 2014 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. pub mod two_tuple { trait T {} struct P<'a>(&'a T + 'a, &'a T + 'a); pub fn f<'a>(car: &'a T, cdr: &'a T) -> P<'a> { P(car, cdr) } } pub mod two_fields { trait T {} struct P<'a> { car: &'a T + 'a, cdr: &'a T + 'a } pub fn f<'a>(car: &'a T, cdr: &'a T) -> P<'a> { P{ car: car, cdr: cdr } } } fn main() {} </ins>

Related discussion:
text: Swapping the order of the branches compiles fine. cc
Just checked: this fails with a normal closure too, not just a proc.
Compiles fine now but potentially needs a test.
Code change:
<ins> // Copyright 2014 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. pub mod two_tuple { trait T {} struct P<'a>(&'a T + 'a, &'a T + 'a); pub fn f<'a>(car: &'a T, cdr: &'a T) -> P<'a> { P(car, cdr) } } pub mod two_fields { trait T {} struct P<'a> { car: &'a T + 'a, cdr: &'a T + 'a } pub fn f<'a>(car: &'a T, cdr: &'a T) -> P<'a> { P{ car: car, cdr: cdr } } } fn main() {} </ins>

Related discussion:
text: Versions: Code to reproduce the ICE: Compilation output:
Seems to be fine now but potentially needs a test.
Nope, still failing. An updated example:
That code example fails to compile, but it's because the function signature for is wrong. It should be: When you make that change and make the struct fields public, the code compiles fine. Without the change I also didn't see any internal compiler errors. Rust Version: 0.12.0-pre-nightly, , Linux x8664
Yeah, I think this can be closed.
Flagging as needstest (not sure if one is checked in already)
Code change:
<ins> // Copyright 2014 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. pub mod two_tuple { trait T {} struct P<'a>(&'a T + 'a, &'a T + 'a); pub fn f<'a>(car: &'a T, cdr: &'a T) -> P<'a> { P(car, cdr) } } pub mod two_fields { trait T {} struct P<'a> { car: &'a T + 'a, cdr: &'a T + 'a } pub fn f<'a>(car: &'a T, cdr: &'a T) -> P<'a> { P{ car: car, cdr: cdr } } } fn main() {} </ins>

Related discussion:
text: It gives
cc
Looks like it no longer causes an ICE.
I agree, it is fixed, I close it.
Code change:
rhses: &[quoted::TokenTree]) -> Box<MacResult+'cx> { if cx.trace_macros() { <del> let sp = sp.macro_backtrace().last().map(|trace| trace.call_site).unwrap_or(sp); let mut values: &mut Vec<String> = cx.expansions.entry(sp).or_insert_with(Vec::new); values.push(format!("expands to `{}! {{ {} }}`", name, arg)); </del> <ins> trace_macros_note(cx, sp, format!("expanding `{}! {{ {} }}`", name, arg)); </ins> } // Which arm's failure should we report? (the one furthest along)

Related discussion:
text: Output is: The first message here is inaccurate. The macro-use does not expand to that macro-use. shows the input to macros, not the output. So instead of "expands to:", it should say "expanding:". But changing the behavior to match what the message says would be even better. ;) This is a regression because the error messages are new. used to just dump token streams to stdout (lol).
Introduced in .
Closing -- I believe fixed this.
Code change:
<ins> #![crate_name = "foo"] // @has 'foo/trait.Unsafe.html' // @has - '//*[@class="object-safety-info"]' 'This trait is not object safe.' // @has - '//*[@id="object-safety"]' 'Object Safety' pub trait Unsafe { fn foo() -> Self; } // @has 'foo/trait.Unsafe2.html' // @has - '//*[@class="object-safety-info"]' 'This trait is not object safe.' // @has - '//*[@id="object-safety"]' 'Object Safety' pub trait Unsafe2<T> { fn foo(i: T); } // @has 'foo/trait.Safe.html' // @!has - '//*[@class="object-safety-info"]' '' // @!has - '//*[@id="object-safety"]' '' pub trait Safe { fn foo(&self); } // @has 'foo/struct.Foo.html' // @!has - '//*[@class="object-safety-info"]' '' // @!has - '//*[@id="object-safety"]' '' pub struct Foo; </ins>

Related discussion:
text: So that it is easy for user to recognize object-safe traits. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
for the rustdoc side, just query the doc context with a given traitdef_id.
claim
Can you tell what are the relevant parts of rustdoc that needs to be changed?
sorry for late rely :) Add a field to , its value can be queried with like . Then you can append the object-safety info into the render part here I know little about the render code, could you leave some notes about that?
No, please do not add more fields to Trait. Query at the place it is used. I don't know much about render, may have suggestions.
I'm actually not sure what they want the end result to look like, so I don't know where to tell them to update the code. ;)
maybe it could be a cube icon to the right of the new button? On hover, there would be a tooltip saying or . I'm not sure where you get icons for rustdoc, but have a cube and cube-transparent icon that could be used for object-safe, and object-unsafe traits respectively. The could be reduced to fit in with the rest of the icons in rustdoc. If doesn't want to work on it I'd be happy to give it a go.
Following up from the PR with some UI discussion. I'd prefer not to add more icons up at the top of the page; we're already a bit crowded with icons. And there's no icon that has a broadly understood meaning of "object safe". I like the approach in , to write out "This trait is object-safe." But that PR puts it all the way at the top of the page, which is very high priority - and I would say object safety is more medium priority, so it should be lower on the page. One possibility would be to make an subheading in the top-doc docblock, but that results in using a lot of space for this. Our h2's are big! What about this: Under "Implementors", we could have at the very top "This trait is object safe. References to types that implement this trait can be automatically coerced to ".