jiebi/CodeConvo huggingface dataset:
Code change:
// Avoid pointing to the same function in multiple different // error messages. if span != DUMMY_SP && self.fn_self_span_reported.insert(self_arg.span) { <ins> self.explain_iterator_advancement_in_for_loop_if_applicable( err, span, &move_spans, ); </ins> let func = tcx.def_path_str(method_did); err.subdiagnostic(CaptureReasonNote::FuncTakeSelf { func,

Related discussion:
text: In this case, turns out there's only one: And there we see that there is already some conditional suggestion being made; it calls . And it seems there's a family of those . So I think it would make sense to try to write your own or something like that. You'll need to figure out how to sort of "back track" from the MIR back to the HIR or the AST so you can figure out whether you're inside a loop. I would study the code in to try to figure out how to do that. And don't forget to write a handful of regression tests in somewhere, maybe in : https://rustc-dev- It might also be possible to perform this check at a higher level, say, in . If you can figure out that you're in a for loop, and that the user is trying to call on the iterator, then you could raise the error then.
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. #![deny(exceeding_bitshifts)] #![allow(unused_variables)] fn main() { let n = 1u8 << 8; let n = 1u8 << 9;   //~ ERROR: bitshift exceeds the type's number of bits let n = 1u16 << 16; let n = 1u16 << 17; //~ ERROR: bitshift exceeds the type's number of bits let n = 1u32 << 32; let n = 1u32 << 33; //~ ERROR: bitshift exceeds the type's number of bits let n = 1u64 << 64; let n = 1u64 << 65; //~ ERROR: bitshift exceeds the type's number of bits let n = 1i8 << 8; let n = 1i8 << 9;   //~ ERROR: bitshift exceeds the type's number of bits let n = 1i16 << 16; let n = 1i16 << 17; //~ ERROR: bitshift exceeds the type's number of bits let n = 1i32 << 32; let n = 1i32 << 33; //~ ERROR: bitshift exceeds the type's number of bits let n = 1i64 << 64; let n = 1i64 << 65; //~ ERROR: bitshift exceeds the type's number of bits let n = 1u8 >> 8; let n = 1u8 >> 9;   //~ ERROR: bitshift exceeds the type's number of bits let n = 1u16 >> 16; let n = 1u16 >> 17; //~ ERROR: bitshift exceeds the type's number of bits let n = 1u32 >> 32; let n = 1u32 >> 33; //~ ERROR: bitshift exceeds the type's number of bits let n = 1u64 >> 64; let n = 1u64 >> 65; //~ ERROR: bitshift exceeds the type's number of bits let n = 1i8 >> 8; let n = 1i8 >> 9;   //~ ERROR: bitshift exceeds the type's number of bits let n = 1i16 >> 16; let n = 1i16 >> 17; //~ ERROR: bitshift exceeds the type's number of bits let n = 1i32 >> 32; let n = 1i32 >> 33; //~ ERROR: bitshift exceeds the type's number of bits let n = 1i64 >> 64; let n = 1i64 >> 65; //~ ERROR: bitshift exceeds the type's number of bits let n = 1u8; let n = n << 8; let n = n << 9; //~ ERROR: bitshift exceeds the type's number of bits let n = 1u8 << -9; //~ ERROR: bitshift exceeds the type's number of bits let n = 1u8 << (4+4); let n = 1u8 << (4+5); //~ ERROR: bitshift exceeds the type's number of bits } </ins>

Related discussion:
text: Currently overlong bit shifts are undefined behavior because that's how llvm rolls--. But even when they aren't, we should warn on something like where happens to be , since it's a useless operation that couldn't possibly return anything interesting. There's a and I imagine it'd be a common gotcha since other languages tend to read unadorned integral literals as 32bit s and then promote the in before doing the actual shift.
I think this can be closed, resolved in
Hooray!
Code change:
match base_cmt.cat { mc::cat_upvar(mc::Upvar { id: ty::UpvarId { var_id: vid, .. }, .. }) | mc::cat_local(vid) => { <del> self.reassigned |= self.node == vid && Some(field) == self.field </del> <ins> self.reassigned |= self.node == vid && (self.field.is_none() || Some(field) == self.field) </ins> }, _ => {} }

Related discussion:
text: Actually what happens here is the following: The tuple you create in is moved, because it is not . When you perform the you move out of , into , leaving uninitialized. Your assignment to is basically to uninitialized memory, and doesn't have an effect. When you perform the assertion you see the old value of , because your assignment to had no effect. The whole thing is confusing because Rust does not warn when you perform useless assignments to moved variables, and it probably should. The whole thing becomes obviously when you add a statement that uses in the match arm: Edit: the labels you have assigned to this issue are incorrect.
Don't we see the new value , even though we're accessing , when performing the assertion, which causes it to fail? Doing this without a match statement passes the same assertion sucessfully:
Oops, you are correct, I am mistaken :( , mitaa wrote:
heh, I made the same mistake. Typed out most of a response and then realised that I'd mis-read the code.
Code change:
visibility: self.vis.clean(cx), stability: self.stab.clean(cx), deprecation: self.depr.clean(cx), <del> def_id: cx.tcx.hir().local_def_id(self.id), </del> <ins> def_id: did, </ins> inner: FunctionItem(Function { decl, generics, <del> header: self.header, </del> <ins> header: hir::FnHeader { constness, ..self.header }, </ins> }), } }

Related discussion:
text: Regression from 1.26.0 to 1.27.0 and later. See for example See also and
Code change:
intravisit::walk_crate(this, krate); }); }); <ins> compiler.session().abort_if_errors(); </ins> let ret: Result<_, ErrorReported> = Ok(collector.tests); ret }) <del> }) .expect("compiler aborted in rustdoc!"); </del> <ins> }); let tests = match tests { Ok(tests) => tests, Err(ErrorReported) => return 1, }; </ins> test_args.insert(0, "rustdoctest".to_string());

Related discussion:
text: I have a no_std crate that imports std when testing: However, I get this error during testing: Allocating on the heap during testing does appear to work, so I'm assuming this is just a case of the warning still being emitted.
I have the same issue. Any update?
builds the crate both as a library (for doctests) and as a test executable. You only pull in std for the test executable, so the error message could be coming from building as a library.
I have the same issue, error message seems to be spurious
Yeah, the error message is emitted when building the library. Funnily enough, it does not cause the build to fail. That is, still continues running and then exits with success (0). Sadly, there is currently no way to link in a default allocator (or for that matter) for doctests. There is the unstable feature that provides , but I don't see how to achieve something similar without relying on unstable features. I simply use until this is fixed.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.
If you don't put inside the doctest it will be linked against even when testing a crate, you can think of each doctest as a separate crate. If you do want a different allocator you can add a static like in a normal binary. Even though this error message is printed the doc tests should still be running.
Also see the error is basically spurious.
Code change:
intravisit::walk_crate(this, krate); }); }); <ins> compiler.session().abort_if_errors(); </ins> let ret: Result<_, ErrorReported> = Ok(collector.tests); ret }) <del> }) .expect("compiler aborted in rustdoc!"); </del> <ins> }); let tests = match tests { Ok(tests) => tests, Err(ErrorReported) => return 1, }; </ins> test_args.insert(0, "rustdoctest".to_string());

Related discussion:
text: I noticed this in the output running locally: and that didn't make tests fail. Cc:
Same with panic_unwind:
This error message is printed when running , but before running any test. The code printing it is in . It looks like rustdoc is using that code in order to load the crate and find doctests in it. But since it’s not actually compiling this crate, not having an allocator is not a problem. So I think there are two issues: rustdoc keeps doing its thing even though there are errors. It probably should call something like on its instance at some point. This error should not occur in the first place. One way to inhibit it would be to tell that we’re "compiling" an rlib () rather than some other crate type. rlibs do not need (yet) to have an allocator defined. This is possibly this line: The first issue could in some other situation hide a real problem, but in this case it makes the second one mostly harmless. The only bad consequence is some noise in the output of a test run.
Related:
modify labels: +T-rustdoc
Error: Parsing label command in failed: labels +T-rustdo... Please let know if you're having trouble with this bot.
Code change:
<ins> trait Foo {} trait T { fn a(&self) -> impl Foo { self.b(|| 0) //~^ ERROR no method named `b` found for reference `&Self` in the current scope } } fn main() {} </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'error: internal compiler error: expected type of closure to be a closure', 'error: internal compiler error: expected type of closure to be a closure' File: --auto-reduced (treereduce-rust): original: Version information Command: &lt;!-- Include a backtrace in the code block by setting in your environment. E.g. . --&lt;details&lt;summary&lt;strongProgram output&lt;/strong&lt;/summary&lt;p&lt;/p&lt;/details&lt;!-- query stack: [mirbuilt] building MIR for [unsafetycheckresult] unsafety-checking [mirconst] preparing for borrow checking [mirpromoted] promoting constants in MIR for [mirborrowck] borrow-checking [typeofopaque] computing type of opaque [typeof] computing type of [checkmoditemtypes] checking item types in top-level module [analysis] running analysis passes on this crate --
regression in ping
nice, that's one of the ICE messages I just too
Code change:
<ins> trait Foo {} trait T { fn a(&self) -> impl Foo { self.b(|| 0) //~^ ERROR no method named `b` found for reference `&Self` in the current scope } } fn main() {} </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'no entry found for key'', 'thread 'rustc' panicked at 'no entry found for key'' 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
Regression in nightly-2023-11-08 / ping
I think is fixing an issue that may have the same root cause.
Code change:
<ins> trait Foo {} trait T { fn a(&self) -> impl Foo { self.b(|| 0) //~^ ERROR no method named `b` found for reference `&Self` in the current scope } } fn main() {} </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' 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
Regression in nightly-2023-11-08 / ping
This should be fixed by
I'm intrigued as to why you believe could rectify this problem. The issue can be distilled as follows: It results in a panic at due to the closure utilizing the type from its outermost function, eventually returning . This issue appears to be unrelated to .
You're provably correct, and I am likely wrong about the root cause of the issue. I will look tomorrow. Feel free to claim this issue if you've already found a solution in the process of investigation.
Code change:
}); // We're done if we found errors, but we already emitted them. <del> if let Some(reported) = reported { assert!(errors.is_empty()); </del> <ins> if let Some(reported) = reported && errors.is_empty() { </ins> return reported; } assert!(!errors.is_empty());

Related discussion:
text: <!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'assertion failed: errors.isempty()'', 'thread 'rustc' panicked at 'assertion failed: errors.isempty()'' 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: [typeck] type-checking [analysis] running analysis passes on this crate --
cc
Code change:
<ins> pub enum Foo { Variant { #[doc(hidden)] a: i32, // @set b = "$.index[*][?(@.name=='b')].id" b: i32, #[doc(hidden)] x: i32, // @set y = "$.index[*][?(@.name=='y')].id" y: i32, }, // @is "$.index[*][?(@.name=='Variant')].inner.variant_kind" '"struct"' // @is "$.index[*][?(@.name=='Variant')].inner.variant_inner.fields_stripped" true // @is "$.index[*][?(@.name=='Variant')].inner.variant_inner.fields[0]" $b // @is "$.index[*][?(@.name=='Variant')].inner.variant_inner.fields[1]" $y // @count "$.index[*][?(@.name=='Variant')].inner.variant_inner.fields[*]" 2 } </ins>

Related discussion:
text: At some point their should also be a for , and probably a way to tell what position each of the non stripped items are, as currently each of these 3 variants are documented with the same inner. but HTML gets a good representation:  The solution is probably to do what we do for structs, and store the , and a , such that each field of a varient gets an to hold the . We also should have a numfields, as even in that schema, you can't tell the difference between This also effects struct AFAIKT. I don't think this needs to be done now. I'll file an issue for it. Originally posted by in modify labels: +A-rustdoc-json +T-rustdoc
Related:
Code change:
<ins> // check-pass use std::io::Write; struct A(Vec<u8>); struct B<'a> { one: &'a mut A, two: &'a mut Vec<u8>, three: Vec<u8>, } impl<'a> B<'a> { fn one(&mut self) -> &mut impl Write { &mut self.one.0 } fn two(&mut self) -> &mut impl Write { &mut *self.two } fn three(&mut self) -> &mut impl Write { &mut self.three } } struct C<'a>(B<'a>); impl<'a> C<'a> { fn one(&mut self) -> &mut impl Write { self.0.one() } fn two(&mut self) -> &mut impl Write { self.0.two() } fn three(&mut self) -> &mut impl Write { self.0.three() } } fn main() {} </ins>

Related discussion:
text: Here is an example which uses a RPIT on a borrowed type in three different ways: IMO this is perfectly reasonable code and (EDIT: see below). On stable () we have the following: And on beta () and nightly () we get some additional errors: EDIT: On second thought, I guess the first error (on stable) is reasonable, since we are actually returning a in that case. If you either use in the body or in the return type then the error goes away. But the second error is still a regression. It most recently worked on: rustc 1.66.0 ( 2022-12-12) : modify labels: +regression-from-stable-to-beta -regression-untriaged
This is . Cc It is related to the invariance: Another case that doesn't rely on member constraints in the second function and yields a different error message: I also found a distantly related regression that doesn't require invariance. It looks like a missed subtyping opportunity:
Another version using TAIT: At this point there are two classes of regression: The first is related to the fact that and the the second requires more subtyping relations. label I-types-nominated T-types T-compiler
WG-prioritization assigning priority (). label -I-prioritize +P-critical
From beta crater: https://crater- https://crater- https://crater- https://crater- https://crater-
unnominating as it will get fixed by which is approved again. Have to try to get this into beta though, only have 1 more day for that
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::empty_line_after_doc_comments)] #![allow(clippy::assertions_on_constants)] #![feature(custom_inner_attributes)]

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:
<del> Subproject commit fc5d0cc583cb1cd35d58fdb7f3e0cfa12dccd6c0 </del> <ins> Subproject commit 8b7f7e667268921c278af94ae30a61e87a22b22b </ins>

Related discussion:
text: Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.
Code change:
println!("cargo:rustc-cfg=llvm_component="{}"", component); } <ins> if major >= 9 { println!("cargo:rustc-cfg=llvm_has_msp430_asm_parser"); } </ins> // Link in our own LLVM shims, compiled with the same flags as LLVM let mut cmd = Command::new(&llvm_config); cmd.arg("--cxxflags");

Related discussion:
text: Every Rust nightly as of approximately Jan 27, 2019 has to build my msp430 application due to assembler errors of the following form: This is due to in the LLVM backend that has been , but hasn't managed to propagate downstream to yet (thank you for the help). As I understand it, Rust only updates the LLVM backend occassionally, along with some patches; Is it possible to cherry pick this patch so that the msp430 backend works again before the next version bump? I would open this issue on the Rust LLVM fork, but Issues seems to be disabled for this repository...
I think we're generally speaking tracking trunk quite closely so should be feasible to bump here, cc
Friendly ping... has there been any update on this? I'd host my own copy of LLVM with the fix for the time being, but I doubt CI would like that...
pointed me to . Doesn't seem too difficult to follow; I think I should be able to do this myself, hopefully within the week, but at the very least soon :).
Rust now uses LLVM 9, could you try with recent nightly?
It was fun while it lasted. The transition to LLVM 9 causes a separate in my AT2XT repo<sup1</sup, so I'm unsure if we've regressed and this particular issue still applies, or if this is simply a totally separate error and the "r2" error was still fixed. Unfortunately, due to illness, I don't think I can work on this for about another week. Could you ping me again then please if I haven't responded at all. I'll just send another LLVM patch if necessary since I know how to do it now. (cc: Have you seen this? msp430 Rust still shouldn't be using LLVM's assembler for msp430 AFAIK. It may be ready for use however.)
You can try enabling it here but I have no idea if it works at all:
I'm looking into this for two evenings already, but still not found where the bug is. What I know so far: 1) Compiling with and both fail, which means it's probably not a issue, because doesn't need option. 2) Compiling with flag and then using to produce the assembly works fine. Which means the bug is specific to how Rust invokes LLVM.
Code change:
println!("cargo:rustc-cfg=llvm_component="{}"", component); } <ins> if major >= 9 { println!("cargo:rustc-cfg=llvm_has_msp430_asm_parser"); } </ins> // Link in our own LLVM shims, compiled with the same flags as LLVM let mut cmd = Command::new(&llvm_config); cmd.arg("--cxxflags");

Related discussion:
text: I will keep debugging this and post here if I find something more.
For reference, the error: Which means that the MSP430 AsmParser cannot be found (even though it does exist). Looking at we see that we indeed fail to initialize it.
no so long ago the asm parser didn't exist on msp430, the inline assembly was just inserted as is into resulting assembly and everything was fine. What exactly have changed that now the asm parser is required? P.S. We can also get rid of option, since we can also produce object files now too.
The integrated assembler was enabled in , which is why it is now attempted to be used. (The option in rustc does not control this behavior.)
Reopening until there is confirmation that this is fixed...
Thank you for your work. There is still a bit more work to be done to get msp430 compiling again. The fix is involved/breaking, and and I (mainly me) will not be able to fix this until the week of August 11th.
I tested 1.38.0-nightly ( 2019-08-07) and can confirm that this issue has been resolved. I think you can close this now, thank you.
Code change:
use core::iter::{FromIterator}; use core::mem::swap; use core::ptr; <ins> use core::fmt; </ins> use slice; use vec::{self, Vec};

Related discussion:
text: If I run the following code : I get the following error : I don't see any reason for the trait Debug not to be implemented for BinaryHeap. If seeing the nodes of it is a problem, at least a could be enough.
Should be fine to display the elements -- probably an oversight?
Probably an oversight. Implementing the solution shouldn't take more than a line (few at most) and it is annoying that you can't easily implement debug for struct owning one BinaryHeap.
Code change:
#![feature(core_intrinsics)] #![feature(dropck_eyepatch)] #![feature(generic_param_attrs)] <del> #![feature(needs_drop)] </del> #![cfg_attr(test, feature(test))] #![allow(deprecated)]

Related discussion:
text: About to submit a PR for exposing intrinsics::needs_drop under mem. Needs a tracking issue. Here it is!
The PR is
fcp merge Seems like this may be good to stabilize!
Team member has proposed to merge this. The next step is review by the rest of the tagged teams: [x] [x] [x] [x] [x] [x] No concerns currently listed. Once these reviewers reach consensus, 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.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period is now complete.