jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: defaults for type parameters are only allowed in `struct`, `enum`, `type`, or `trait` definitions --> $DIR/type-param-defaults.rs:6:16 | LL |     type Assoc<T = u32>; |                ^^^^^^^ error: defaults for type parameters are only allowed in `struct`, `enum`, `type`, or `trait` definitions --> $DIR/type-param-defaults.rs:11:16 | LL |     type Assoc<T = u32> = u64; |                ^^^^^^^ error: defaults for type parameters are only allowed in `struct`, `enum`, `type`, or `trait` definitions --> $DIR/type-param-defaults.rs:16:16 | LL |     type Assoc<T = u32> = T; |                ^^^^^^^ error: aborting due to 3 previous errors </ins>

Discussion:
I tried this code: I expected to see this happen: It not work correctly as if you remove it shouts at you saying its unsupported and will be a hard error one day. Instead, this happened: defaults on GATs seem to function perfectly fine version from playground: cc this is probably should either be allowed or a hard error before stabilisation?
one issue is that we ignore defaults on the gat in impls
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
#[must_use] #[stable(feature = "rust1", since = "1.0.0")] fn le(&self, other: &Rhs) -> bool { <del> matches!(self.partial_cmp(other), Some(Less | Equal)) </del> <ins> // Pattern `Some(Less | Eq)` optimizes worse than negating `None | Some(Greater)`. !matches!(self.partial_cmp(other), None | Some(Greater)) </ins> } /// This method tests greater than (for `self` and `other`) and is used by the `>` operator.

Discussion:
The manual version: The manual version ASM: The derived version: The derived version ASM: The diff is that while the manual version does: derived version does: All the other operators are optimized properly.
LLVM can't properly optimize the match against Some(Less Some(Greater) and negate the result, LLVM does find a way to optimize the code, because the IR we generate is somewhat simpler having to handle only one of the Some() cases. I didn't really look into how to maybe teach LLVM to handle this case, and didn't see anything obvious in the way we generate IR that could be improved here either. Should I prepare a PR to adjust the default impl of with a comment that explains why it's written that way, or should we investigate more here?
I wonder if this issue is related to
We could test it in next nightly.
Well, this issue doesn't fixed by it (which is expected because we changed MIR of && and , not match) so we need to make changes in LLVM or change our generated code.
Created PR with fix.
Upstream fix for LLVM:
Change:
<ins> // run-rustfix #![deny(unused_qualifications)] mod foo { pub fn bar() {} } mod baz { pub mod qux { pub fn quux() {} } } fn main() { use foo::bar; bar(); //~^ ERROR unnecessary qualification use baz::qux::quux; quux(); //~^ ERROR unnecessary qualification } </ins>

Discussion:
In the middle of a large refactoring that was mostly automated by rust-analyzer's structural-search-and-replace, I had a lot of qualified paths that shouldn't be qualified. I made do with a regular text-based search-and-replace since I couldn't find a better way, but I think that better way could have been , because introducing an import for the relevant type once per file is much easier than replacing all uses manually. As such, it would be nice if the unnecessary qualification lint had a machine-applicable suggestion attached to it. However, one interesting thing about this is that I also had warnings about the import for that same type being unused. I don't know whether it would be possible with the current compiler infrastructure to create mutually-exclusive suggestions. Either way the suggestion would be helpful, since a simple could disable the automatic removal of the imports.
I second that should be applicable. To fix the violations I almost found and removed the qualified prefix one by one.
Mentoring instructions: Add a new .
Change:
if self.with_self_ty_parens && b.generic_params.len() > 0 => {} ast::TyKind::ImplTrait(_, bounds) if bounds.len() > 1 => {} _ => { <del> let spans = r .span .find_ancestor_inside(ty.span) .map(|r| (ty.span.with_hi(r.lo()), ty.span.with_lo(r.hi()))); </del> <ins> let spans = if !ty.span.from_expansion() { r.span .find_ancestor_inside(ty.span) .map(|r| (ty.span.with_hi(r.lo()), ty.span.with_lo(r.hi()))) } else { None }; </ins> self.emit_unused_delims(cx, ty.span, spans, "type", (false, false), false); } }

Discussion:
This code: Creates this diagnostic: I ran (note that I created a local project called playground) which created this output: This told me to create an issue here. Going into more depth regarding the issue - the macro expands after one step like so: and we can see where the issue is: These parentheses are indeed fully removable, and it points to an issue in the macro definition. By changing to the compiler no longer emits the warning, because now it expands to which is properly recognized as a tuple with one element, rather than a type surrounded by redundant parentheses. Another way to fix it is to remove the outer parentheses in the macro call: which does compile without warnings, but breaks usage of the macro with tuples with more than two elements: as while its fine to remove the parentheses when there is only one element between the angle brackets ( to ), it is not fine when there are more than one element in the tuple ( to ). Importantly, the compiler still emits the unused parentheses warning and suggests their removal when the macro is called with three types when you haven't removed the parentheses (). Therefore, part of the issue is that rustc detects the problem, and assumes it can fix it by going straight to the macro and correcting it, neglecting previous expansions of the macro which require the currently redundant parentheses. I say part of the issue, because going back to the original diagnostic: rustc marks and as removable, and it suggests you do so: when the diagnostic should really only be suggesting the removal of the outer brackets. I'm not too sure why this one happens. Using Syn's terminology, my best guess is that it has something to do with the span of the outer parentheses including the inner and after expansion. : Also tried with nightly (had identical results):
Change:
} /// A cheap, mutable reference-to-mutable reference conversion. <ins> /// /// **Note: this trait must not fail**. If the conversion can fail, use a dedicated method which /// return an `Option<T>` or a `Result<T, E>`. /// /// # Generic Impls /// /// - `AsMut` auto-dereference if the inner type is a reference or a mutable /// reference (eg: `foo.as_ref()` will work the same if `foo` has type `&mut Foo` or `&&mut Foo`) /// </ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait AsMut<T: ?Sized> { /// Performs the conversion.

Discussion:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart.

:+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!
Change:
<ins> trait Trait<T> {} fn foo<T>() -> dyn Trait<T> where dyn Trait<T>: Sized, // pesky sized predicate { 42 //~^ ERROR mismatched types } 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
bisected to cc
This can be made to ICE on stable as well:
duplicate of

<!-- 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
almost exactly 3 years old :cake: :partying_face: :pinata: searched toolchains nightly-2020-04-17 through nightly-2023-04-22 Regression in nightly-2020-04-23 found 7 bors merge commits in the specified range commit[0] 2020-04-21: Auto merge of - spastorino:dyn-fnonce-alignment, r=nikomatsakis commit[1] 2020-04-22: Auto merge of - ehuss:update-cargo, r=ehuss commit[2] 2020-04-22: Auto merge of - JohnTitor:rollup-vh6dut5, r=JohnTitor commit[3] 2020-04-22: Auto merge of - nnethercote:bitcode-in-rlib, r=alexcrichton commit[4] 2020-04-22: Auto merge of - Dylan-DPC:rollup-iunh61a, r=Dylan-DPC commit[5] 2020-04-22: Auto merge of - nnethercote:alphabetize-C-and-Z-options, r=petrochenkov commit[6] 2020-04-22: Auto merge of - Dylan-DPC:rollup-rvm6tfy, r=Dylan-DPC probably ? cc
I feel like i've seen this before -- probably a dupe? Or at least I think I've chatted with about this.
Could be :D probably 90% of the ICEs I am seeing are already reported in some way or another and sometimes one might slip through
different stacktrace with debug assertions: `
Change:
tv_nsec: 1_000_000_000 - 1, }; <ins> fn saturating_cast_to_time_t(value: u64) -> libc::time_t { if value > <libc::time_t>::max_value() as u64 { <libc::time_t>::max_value() } else { value as libc::time_t } } </ins> impl Condvar { pub const fn new() -> Condvar { // Might be moved and address is changing it is better to avoid

Discussion:
I have encountered what I think is unexpected behavior from on OSX: when called with "large" values the call will return immediately, instead of waiting for an call. What constitutes "large" is variable, and appears to correspond to the current value in the system monotonic clock source. The following code reproduces the issue: If you run the code above with the "small" value uncommented the internal loop only runs once, waiting for the 1-second sleep to expire before is called. But if you run with the "large" value uncommented, the internal loop runs a very large number of times as each call to returns almost immediately. As noted above, the actual value of "large" decreases over time, I believe based on . I unfortunately couldn't come up with a way to prove this is the case. I've seen this behavior on OSX Yosemite and Sierra. Edit: this happens on 1.11, 1.12, beta, and nightly.
This is likely related to the implementation using unchecked arithmetic and something overflowing. I'll tweak it to much Linux and test out to make sure it works.
Hm no that's correctly handling overflow... Hmm...
Fixed by
Change:
use rustc_data_structures::fx::FxHashSet; use rustc_errors::struct_span_err; <del> use rustc_errors::ErrorGuaranteed; </del> <ins> use rustc_errors::{Diagnostic, ErrorGuaranteed}; </ins> use rustc_hir as hir; use rustc_infer::infer::TyCtxtInferExt; use rustc_middle::ty::subst::GenericArgKind;

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 you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --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. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
This could use some work, too, I think. Maybe "impl mentions type from outside the current crate" might be a sufficient replacement, though we should probably make sure that wording is compatible with current coherence rules. Though, in this case, for a non- self type like , we could then replace that^ message with something even more specific. I'm a bit skeptical of mentioning "try implementing on " when we have , since implementing something for and can have very different meanings depending on the signatures inside the trait.
Let's improve this case! claim
This was actually closer to my original error I got, it uses a type alias to create some extra confusion:
Amazing example :) thanks, I'm on it
This is a reproducible example without serde!
Change:
dontValidate: true, }; } <del> if (module === true) { </del> <ins> if (is_module === true) { </ins> results[fullId] = { id: i, index: -1,

Discussion:
I was trying to find in rustdoc, but that doesn't show up anywhere if I just search for : It does show up if I search for () so there's a workaround, but I think it'd be nice if when I type an exact name, things with that exact name show up at the top, or something.
It's supposed to, so some adjustments need to be done on the "search engine". I'll take a look.
Change:
[[package]] name = "gccjit" version = "1.0.0" <del> source = "git+https://github.com/antoyo/gccjit.rs#eefb8c662d61477f34b7c32d26bcda5f1ef08432" </del> <ins> source = "git+https://github.com/antoyo/gccjit.rs#fe242b7eb26980e6c78859d51c8d4cc1e43381a3" </ins> dependencies = [ "gccjit_sys", ]

Discussion:
Running on s390x fails when attempting to build due to: This seems to be caused by a dependency on libc 0.1.12 from gccjit_sys. This version is very old (from about 2015), and does not yet support the s390x architecture at all. could this be updated to a more recent libc version? If so, would you like me to send a patch against ?
Yes, please!
Thanks for the quick merge! I see still fails for now, because the rust build still seems to pull in the commit of , probably because of the in . Will this be pulled forward automatically at some point, or do I need to submit another PR? (If so, against which repo?)
The fastest would be to update the in this repo (rust-lang/rust). I would appreciate if you submit a PR for this. Thanks!
I've updated the dependency to the current head commit and rebuilt. This automatically removed the libc 0.1 dependency from ; it is now using 0.2.112 (the version that was also already present in ) everywhere, which is fine for s390x.
With that PR applied, now passes on s390x.
Change:
trait Bar { fn f(&self) { <del> self.g(); //~ ERROR the method `g` exists for reference `&Self`, but its trait bounds were not satisfied </del> <ins> // issue #105788 self.g(); //~ ERROR no method named `g` found for reference `&Self` in the current scope </ins> } }

Discussion:
Given the following The current output is: The second error is not reasonable, since we don't allow associated items in auto trait. Ideally the output should look like: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I spent some time to investigate it, I tried to filter the candidates from auto trait. But seems here have two predicates, and the message for the second error comes from the first : I'm still trying to understand the code.
claim
Change:
let cid = key.value; let def_id = cid.instance.def.def_id(); <del> if let Some(id) = tcx.hir().as_local_hir_id(def_id) { let tables = tcx.typeck_tables_of(def_id); // Do match-check before building MIR // FIXME(#59378) check_match may have errored but we're not checking for that anymore tcx.check_match(def_id); if let hir::BodyOwnerKind::Const = tcx.hir().body_owner_kind_by_hir_id(id) { tcx.mir_const_qualif(def_id); } // Do not continue into miri if typeck errors occurred; it will fail horribly if tables.tainted_by_errors { return Err(ErrorHandled::Reported) } }; </del> <ins> if def_id.is_local() && tcx.typeck_tables_of(def_id).tainted_by_errors { return Err(ErrorHandled::Reported); } </ins> let (res, ecx) = eval_body_and_ecx(tcx, cid, None, key.param_env); res.and_then(|place| {

Discussion:
Super-High-Level Instructions: Replace with And then follow up by making sure that the compiler doesn't ICE anywhere (e.g. during MIR building). It should probably "just work" nowadays. A crater run isn't necessary, as this will only ICE if an error wasn't handled properly. Successfully compiling code is unaffected.
I took a look at this and all tests seem fine in just dropping in the code you have above as you said. However I just wanted to check is no longer needed? Pretty unfamiliar with this code so I wanted to confirm before submitting as it's not explicitly mentioned in the other thread that it should be removed.
Yes that should be removed, too. It will automatically be run when fetching the MIR of the current constant.
ok, cool! I have filed a PR for this in Let me know if anything needs to be updated!
Change:
binding, ) .ok()?; <ins> // Make sure we select the same method that we started with... if Some(method.def_id) != self.typeck_results.borrow().type_dependent_def_id(call_expr.hir_id) { return None; } </ins> // Unify the method signature with our incompatible arg, to // do inference in the *opposite* direction and to find out // what our ideal rcvr ty would look like.

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. --Hello, I am sorry, but I wasn't able to reproduce the bug outside my company's project (proprietary and which I don't have the permission to share), so I can't really help here. Code like this resides in proc-macro transformed function ( from leptos) and inside recursivelly calling macro. Here is how approximately it looks: <!-- 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. --Fails on both nightly and stable, backtrace if from nightly. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsHope this helps and thank for your work.
Relabeling issues which don't have a runnable reproduction (as opposed to not having a minimized one) to the new label S-needs-repro. label +S-needs-repro -E-needs-mcve
I think I encountered the same bug. A minimal example is below. I think the problem is a lookup, which includes the unimplemented trait without checking the length of the argument list before accessing. : Also fails on nightly. <details<summary<strongnightly ructc-</strong</summary<p</p</details
Maybe inside rollup ? cc
I ran into this ICE and minimized my case to the following reproducer. Its slightly different way to get to the same case as 's code above. Still happens from stable 1.77.2 to nightly 2024-04-19. When doing a bisection I get nightly-2023-05-16.
Change:
<ins> // Copyright 2018 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. struct S { x: u8 /// The id of the parent core y: u8, } //~^^^ ERROR found a documentation comment that doesn't document anything fn main() {} </ins>

Discussion:
I had this code: The actual error of course here, would be that there is a missing comma after the . However the error message given by the compiler was: error: expected , or , found -- | 16 | #[doc = "The id of the parent core"] | ^ | = help: struct fields should be separated by commas This isn't a particularly important issue, but as mentioned by someone I spoke to regarding this error, the error messages given by the compiler are usually very helpful, and I feel it is worth maintaining this standard.
to fix this, should emit the error for a useless doc comment and a missing comma / brace if it encounters both - right now doc comment errors override missing seperators completely. attributes work fine because they are not parsed as a single doc comment token.
Can I take this one if nobody is working on that?
go ahead! Feel free to ask for help if you need. If this is your first contribution, take a look at for setting up the environment.
, Now console output is coming like this Now I have three quick questions for you. 1) In the case when a is missing for middle fields of , should we avoid showing warning, because we have not parsed below fields yet? 2) Should I consider creating a new entry in enum to handle warning? 3) If we have decided to show both and warning, how important it is to show missing warning before warning?
I would elide the missing comma error. Create a PR with in its body so that I'm assigned as reviewer and we can discuss in the context of the code. It seems like you're in the right path. Depending on how the code is laid out, you might be able to try to consume a without failing if it isn't there depending on the success or failure of the previous field.
PR raised