jiebi/CodeConvo huggingface dataset:
Code change:
synth_provided, } } else { <del> let num_missing_args = expected_max - provided; </del> <ins> // Check if associated type bounds are incorrectly written in impl block header like: // ``` // trait Foo<T> {} // impl Foo<T: Default> for u8 {} // ``` let parent_is_impl_block = cx .tcx() .hir() .parent_owner_iter(seg.hir_id) .next() .is_some_and(|(_, owner_node)| owner_node.is_impl_block()); if parent_is_impl_block { let constraint_names: Vec<_> = gen_args.constraints.iter().map(|b| b.ident.name).collect(); let param_names: Vec<_> = gen_params .own_params .iter() .filter(|param| !has_self || param.index != 0) // Assumes `Self` will always be the first parameter .map(|param| param.name) .collect(); if constraint_names == param_names { // We set this to true and delay emitting `WrongNumberOfGenericArgs` // to provide a succinct error for cases like issue #113073 all_params_are_binded = true; }; } </ins> <del> let constraint_names: Vec<_> = gen_args.constraints.iter().map(|b| b.ident.name).collect(); let param_names: Vec<_> = gen_params .own_params .iter() .filter(|param| !has_self || param.index != 0) // Assumes `Self` will always be the first parameter .map(|param| param.name) .collect(); if constraint_names == param_names { // We set this to true and delay emitting `WrongNumberOfGenericArgs` // to provide a succinct error for cases like issue #113073 all_params_are_binded = true; }; </del> <ins> let num_missing_args = expected_max - provided; </ins> GenericArgsInfo::MissingTypesOrConsts { num_missing_args,

Related discussion:
text: <!-- [31mICE[0m: Rustc '--crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error[E0107]: trait takes 1 generic argument but 0 generic arguments were supplied', 'error: internal compiler error[E0107]: trait takes 1 generic argument but 0 generic arguments were supplied' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc :thinking:
claim
Code change:
//@aux-build:proc_macro_attr.rs:proc-macro <ins> // Flaky test, see https://github.com/rust-lang/rust/issues/113585. //@ignore-32bit //@ignore-64bit </ins> #![warn(clippy::needless_arbitrary_self_type)]

Related discussion:
text: In , clippy CI , and I don't think that can be caused by my PR: <details</detailsCc
Seems same with my PR Did you try to rebase master for you branch? I resolved it in this way.
your problem was different. the problem Ralf is running into is
The error message and failed test case are both same with my failed CI in my new PR
gotcha - in that case the rebase probably didn't do anything except rerun ci - this only fails some of the time. https://rust- has a plausible explanation
See the discussion at https://rust- I believe this is an issue with ui_test.
This is causing lots of problems in CI, so I'm marking it as critical.
I'll leave it up to you on tracking what needs to be done to revert . It looks like you've been working on it in ui_test, but I'm not involved in clippy development, so I probably shouldn't be the one tracking/fixing things. However, if you have questions on the cargo side, let me know.
Thanks! After the next clippy sync (tomorrow) this should be fixed. On the ui_test side, the failure is now protected against being spurious and 100% reproducible. I'll ship that to miri soon to prevent the same thing from happening there.
Code change:
<ins> error[E0308]: mismatched types --> $DIR/issue-117669.rs:2:20 | LL |     let abs: i32 = 3i32.checked_abs(); |              ---   ^^^^^^^^^^^^^^^^^^ expected `i32`, found `Option<i32>` |              | |              expected due to this | = note: expected type `i32` found enum `Option<i32>` help: consider using `Option::expect` to unwrap the `Option<i32>` value, panicking if the value is an `Option::None` | LL |     let abs: i32 = 3i32.checked_abs().expect("REASON"); |                                      +++++++++++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Related discussion:
text: in Dec '22 introduced a cool new feature to suggest removing the last method call if it would alleviate a type mismatch error. This is particularly using for people wrestling with issues. in Oct '23 introduced another useful feature to suggest to users that they might consider ing an or type in order to solve a type mismatch. Also very cool, and conveniently by the same author Unfortunately, in cases where a method is called, the previous check takes precedence, and the compiler suggests removing that trailing method to get the code to compile. This isn't generally that useful as the expect suggestion, and I can't think of an example where it's a better one. If you can think of one though, please put it below for me to test! surfaced this with but it's more easily demonstrated with ints. I can see two ways to fix this: the trailing method check first, but ignore and types the checks so the option type is checked first. Note that the method check has to be high in the chain as the motive is to quickly suggest removing a call, before adding a whole load of new ones. This means the check has to be one of the first I am going to work on solving it via method 2, as it feels cleaner that the method check doesn't have to know about the and check. If anyone has strong feelings on this, please let me know! Playground No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I think this suggestion for removing the method call is way too eager, as it can easily be wrong and when it's wrong it's quite confusing. Maybe it should instead say that the type was correct before the method call (which is never wrong), nudging the user towards removing the call if they know that it's not important. Instead of strongly saying that it should be removed. Alternatively, it could be special cased to known "unimportant" functions like or .
I think this brings up two issues: should the method call suggestor should do, and say. There was some discussion of this in where it was decided to keep it generic rather than special-casing, but I don't think it's done badly at the moment. Perhaps the wording could be altered?
Code change:
<ins> error[E0308]: mismatched types --> $DIR/issue-117669.rs:2:20 | LL |     let abs: i32 = 3i32.checked_abs(); |              ---   ^^^^^^^^^^^^^^^^^^ expected `i32`, found `Option<i32>` |              | |              expected due to this | = note: expected type `i32` found enum `Option<i32>` help: consider using `Option::expect` to unwrap the `Option<i32>` value, panicking if the value is an `Option::None` | LL |     let abs: i32 = 3i32.checked_abs().expect("REASON"); |                                      +++++++++++++++++ error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Related discussion:
text: it should run I'll focus on the latter here, but if you have examples where removing the method call doesn't make sense we can aggregate them and see if there is a holistic solution?
Code change:
/// # Examples /// /// ```no_run <del> /// # #![feature(bufreader_buffer)] </del> /// use std::io::{BufReader, BufRead}; /// use std::fs::File; ///

Related discussion:
text: Update: this is the tracking issue for: is both unstable and deprecated, it should be removed. There is currently no way to tell whether there is any data buffered inside a BufReader. This is unfortunate because it means that an application has no way to know whether calls to read() and fillbuffer() will return instantly or trigger a potentially expensive call to the underlying Reader. I propose adding an is_empty() method to BufReader to fill this gap.
now that has been merged, I'm guessing this should get the label?
What's left for this to stabilize? I'm parsing bytes from a to MsgPack using . The function will stop parsing once a valid MsgPack value has been found. But in my application the parsing should fail if the buffer hasn't been consumed completely. Checking would probably be the cleanest way to do so.
the method proposed in may also be useful for that purpose, though that may take even longer to land.
This is the tracking issue for: Looks good to me to stabilize. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [ ] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
This seems fine to stabilize, but it seems like it'd be more useful to know how many bytes are buffered, rather than just that there are some number of bytes.
Why not both? Slices have even though it’s somewhat redundant with .
For sure. Would it be reasonable to try to squeeze that into this stabilization?
Sounds ok to me, though we should probably (re)start FCP after the implementation is merged.
Naming wise, I don't think fits since that seems to me like it'd refer to the length of the entire reader rather than just the current buffered data (similarly is a bit confusing). How about and ?
Agreed. Sounds good to me.
Alternatively, we could add to just return the buffer, which is also a thing people want separately from this issue. At that point seems not much worse than so we could have one method instead of three.
Code change:
/// # Examples /// /// ```no_run <del> /// # #![feature(bufreader_buffer)] </del> /// use std::io::{BufReader, BufRead}; /// use std::fs::File; ///

Related discussion:
text: adds and deprecates .
:bell: This is now entering its final comment period, as per the . :bell:
With alternative (and IMO better) proposal just introduced, should this still be going into its final comment period?
fcp cancel Let’s start again after has landed.
proposal cancelled.
We should likely also add a method to for consistency?
That can't be done backwards compatibly.
why not? It's just a , right? Just like .
Oh derp I somehow read that as .
Haha, no worries. Is there even a trait?
No there isn't _Off of the topic of me needing more caffeine, it definitely seems reasonable to add to , and fold it into the same feature gate as 's.
It has been a while since landed. Is this ready to stabilize?
is implemented, but discussed above is not. (I’ve updated the issue’s description with the current status.)
Wait, we aren't proposing to stabilize the (already deprecated) is_empty method are we?
No, sorry I didn’t clarify. An API marked both unstable and deprecated is to be removed (after something like a couple release cycles of deprecation period, which we’re at in this case).
I'm excited to see that this is so close to landing. Is this still waiting on an implementation of ? Would it be possible to track that feature separately to unblock this one?
Bump. Is there anything else blocking stabilization?
Is there any particular reason not to add to ? It seems like a useful enough general-purpose API ("get me however many bytes you can easily give me"), and I found myself looking for such a method while working on parser tooling. Individual implementations could make stricter guarantees about the lower bounds, of which "at least the unconsumed fraction of the last " would be a common one.
Yeah, this has been a while. is this ready for a vote to stabilize?
This issue seems to have been stuck in a strange limbo state for quite a while now. Pinging more people the rfcbot mentioned...
Sorry we dropped the ball here. This is now one method on the and structs. fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [x] [x] [x] [x] [x] [ ] No concerns currently listed.
Code change:
/// # Examples /// /// ```no_run <del> /// # #![feature(bufreader_buffer)] </del> /// use std::io::{BufReader, BufRead}; /// use std::fs::File; ///

Related discussion:
text: Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
There is nothing called in std. Did you mean the trait? A downside is that to add it now we would have to make it a default method, which would (at first) have an inconsistent behavior with for existing impls. We can update impls in std at the same time, but that leaves impls in other crates.
:bell: This is now entering its final comment period, as per the . :bell:
Sorry, yes, I meant . For my use cases, not having a lower bound is fine. Anything that does can use a marker subtrait that encompasses that guarantee. I think the only stipulation should be that it not provide more than , but less is fine. For example, an implementation might copy existing data around on to make a larger contiguous segment, but can't/shouldn't do so in (I think it should be a cheap conversion, wouldn't have been an unreasonable name).
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Code change:
traits::RepeatVec => { tcx.sess.span_note( obligation.cause.span, <del> format!( "the `Copy` trait is required because the  repeated element will be copied").as_slice()); </del> <ins> "the `Copy` trait is required because the  repeated element will be copied"); </ins> } traits::VariableType(_) => { tcx.sess.span_note( obligation.cause.span, "all local variables must have a statically known size"); } <ins> traits::ReturnType => { tcx.sess.span_note( obligation.cause.span, "the return type of a function must have a  statically known size"); } </ins> traits::AssignmentLhsSized => { tcx.sess.span_note( obligation.cause.span,

Related discussion:
text: The following code causes an ICE: Removing the parameter or changing it to be a value instead of a reference stops the crash with an error saying I need to specify a lifetime, which makes me think this is a problem related to inferred lifetimes.
It isn't, you just have to specify a lifetime: ICE-s as well. Returning an unsized type should be a typeck error.
happens to work because it implies , i.e. would also work.
Code change:
let f1: f32 = FromStrRadix::from_str_radix("1p-123", 16).unwrap(); let f2: f32 = FromStrRadix::from_str_radix("1p-111", 16).unwrap(); let f3: f32 = FromStrRadix::from_str_radix("1.Cp-12", 16).unwrap(); <del> assert_eq!(Float::ldexp(1f32, -123), f1); assert_eq!(Float::ldexp(1f32, -111), f2); </del> <ins> assert_eq!(1f32.ldexp(-123), f1); assert_eq!(1f32.ldexp(-111), f2); </ins> assert_eq!(Float::ldexp(1.75f32, -12), f3); assert_eq!(Float::ldexp(0f32, -123), 0f32);

Related discussion:
text: has an unusual format: it takes as it's first parameter where everything else in the trait takes . It should take as it's first parameter for consistency with everything else. It is located in 
+1. There are a few different things to consider here, though: does not operate on any FP number per se like most other operations do, but rather constructs a new FP number from two arguments one of which happens to be FP number. This function’s signature is consistent with most other methods that construct some kind of FP number (e.g. ). We might want to consider whether methods such as shouldn’t just go ahead and take instead. can’t currently be chained, but I see literally 0 cases where anybody would chain this function. cc
Okay, but from a consistency standpoint, it's like 1/80 for vs . It it keeps the same format, it and it's similar functions would probably be better to go at the end or beginning of the function list where they won't be so unusual.
Nominating for 1.0-beta P-backcompat-libs
One should be able to call this thing as a method, one way or another. We need to make sure that is resolved.
0 beta, P-backcompat-libs
I started to fix this.
Code change:
<ins> error: an inner attribute is not permitted in this context --> $DIR/issue-89971-outer-attr-following-inner-attr-ice.rs:11:1 | LL | #![deny(missing_docs)] | ^^^^^^^^^^^^^^^^^^^^^^ ... LL | struct Mew(); | ------------- the inner attribute doesn't annotate this struct | = note: inner attributes, like `#![no_std]`, annotate the item enclosing them, and are usually found at the beginning of source files help: to annotate the struct, change the attribute from inner to outer style | LL - #![deny(missing_docs)] LL + #[deny(missing_docs)] | error: aborting due to previous error </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 encountered an ICE while incorrectly inserting a outer attribute above deriving or inside of a proc-macro. This did not happen with any other derive I tried. <!-- 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
can you please also provide the configuration to reproduce an for your issue? thanks
Sure, sorry for forgetting, here is the mcve: But incase you dont want to see the entire project the for the macro was just: And the of the project to use the macro (and trigger the ICE) was:
Cool, thank you! Here's the result of a bisection: seems to point to PR cc searched nightlies: from nightly-2021-01-01 to nightly-2021-08-11 regressed nightly: nightly-2021-04-12 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Code change:
<ins> // run-rustfix // Regression test for changes introduced while fixing #54505 // This test uses non-literals for Ranges // (expecting no parens with borrow suggestion) use std::ops::RangeBounds; // take a reference to any built-in range fn take_range(_r: &impl RangeBounds<i8>) {} fn main() { take_range(&std::ops::Range { start: 0, end: 1 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::Range { start: 0, end: 1 } take_range(&::std::ops::Range { start: 0, end: 1 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::Range { start: 0, end: 1 } take_range(&std::ops::RangeFrom { start: 1 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeFrom { start: 1 } take_range(&::std::ops::RangeFrom { start: 1 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeFrom { start: 1 } take_range(&std::ops::RangeFull {}); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeFull {} take_range(&::std::ops::RangeFull {}); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeFull {} take_range(&std::ops::RangeInclusive::new(0, 1)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeInclusive::new(0, 1) take_range(&::std::ops::RangeInclusive::new(0, 1)); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeInclusive::new(0, 1) take_range(&std::ops::RangeTo { end: 5 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeTo { end: 5 } take_range(&::std::ops::RangeTo { end: 5 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeTo { end: 5 } take_range(&std::ops::RangeToInclusive { end: 5 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &std::ops::RangeToInclusive { end: 5 } take_range(&::std::ops::RangeToInclusive { end: 5 }); //~^ ERROR mismatched types [E0308] //~| HELP consider borrowing here //~| SUGGESTION &::std::ops::RangeToInclusive { end: 5 } } </ins>

Related discussion:
text: Another problem I encountered while writing tests is that the changes I have made will affect suggestions for code like this: With my changes, the suggestion would be . I believe the correct suggestion would not involve the needless parentheses. This is due to not differentiating between "de-sugared" form coming from and between these de-sugared forms being supplied explicitly as input source code. With this in mind, I think current code is not PR worthy just yet. If of interest, here's the branch:
Left a couple of comments on possible approaches on that commit. The code looks fine.
Code change:
<ins> error[E0107]: trait takes 1 generic argument but 0 generic arguments were supplied --> $DIR/name-same-as-generic-type-issue-128249.rs:4:30 | LL |     fn one(&self, val:  impl Trait<Type: Default>); |                              ^^^^^ expected 1 generic argument | note: trait defined here, with 1 generic parameter: `Type` --> $DIR/name-same-as-generic-type-issue-128249.rs:1:7 | LL | trait Trait<Type> { |       ^^^^^ ---- help: add missing generic argument | LL |     fn one(&self, val:  impl Trait<Type, Type: Default>); |                                    +++++ error[E0107]: trait takes 1 generic argument but 0 generic arguments were supplied --> $DIR/name-same-as-generic-type-issue-128249.rs:7:15 | LL |     fn two<T: Trait<Type: Default>>(&self) -> T; |               ^^^^^ expected 1 generic argument | note: trait defined here, with 1 generic parameter: `Type` --> $DIR/name-same-as-generic-type-issue-128249.rs:1:7 | LL | trait Trait<Type> { |       ^^^^^ ---- help: add missing generic argument | LL |     fn two<T: Trait<Type, Type: Default>>(&self) -> T; |                     +++++ error[E0107]: trait takes 1 generic argument but 0 generic arguments were supplied --> $DIR/name-same-as-generic-type-issue-128249.rs:11:12 | LL |         T: Trait<Type: Default>,; |            ^^^^^ expected 1 generic argument | note: trait defined here, with 1 generic parameter: `Type` --> $DIR/name-same-as-generic-type-issue-128249.rs:1:7 | LL | trait Trait<Type> { |       ^^^^^ ---- help: add missing generic argument | LL |         T: Trait<Type, Type: Default>,; |                  +++++ error: aborting due to 3 previous errors For more information about this error, try `rustc --explain E0107`. </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '--crate-type=lib -ooutputfile -Zdump-mir-dir=dir' 'error: internal compiler error[E0107]: trait takes 1 generic argument but 0 generic arguments were supplied', 'error: internal compiler error[E0107]: trait takes 1 generic argument but 0 generic arguments were supplied' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc :thinking:
claim