jiebi/CodeConvo huggingface dataset:
Change:
= note: `#[warn(while_true)]` on by default error: unnecessary parentheses around `match` head expression <del> --> $DIR/lint-unnecessary-parens.rs:48:11 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:51:11 </ins> | LL |     match (true) { |           ^^^^^^ help: remove these parentheses error: unnecessary parentheses around `let` head expression <del> --> $DIR/lint-unnecessary-parens.rs:51:16 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:54:16 </ins> | LL |     if let 1 = (1) {} |                ^^^ help: remove these parentheses error: unnecessary parentheses around `let` head expression <del> --> $DIR/lint-unnecessary-parens.rs:52:19 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:55:19 </ins> | LL |     while let 1 = (2) {} |                   ^^^ help: remove these parentheses error: unnecessary parentheses around method argument <del> --> $DIR/lint-unnecessary-parens.rs:66:24 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:69:24 </ins> | LL |     X { y: false }.foo((true)); |                        ^^^^^^ help: remove these parentheses error: unnecessary parentheses around assigned value <del> --> $DIR/lint-unnecessary-parens.rs:68:18 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:71:18 </ins> | LL |     let mut _a = (0); |                  ^^^ help: remove these parentheses error: unnecessary parentheses around assigned value <del> --> $DIR/lint-unnecessary-parens.rs:69:10 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:72:10 </ins> | LL |     _a = (0); |          ^^^ help: remove these parentheses error: unnecessary parentheses around assigned value <del> --> $DIR/lint-unnecessary-parens.rs:70:11 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:73:11 </ins> | LL |     _a += (1); |           ^^^ help: remove these parentheses <del> error: aborting due to 15 previous errors </del> <ins> error: aborting due to 17 previous errors </ins>

Discussion:
It doesn't give a warning for the unnecessary parentheses for N1: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
implemented for to check the .
claim
I've encountered an issue I'm not quite sure how to handle :( After getting what looks like a correct solution up with: I am met with the following after starting to build stage-1: Should I open a separate Issue & PR to deal with any errors generated by unused parens or is it within the scope of this issue (and PR coming soon once I write the UI tests) to deal with them?
should be fixed within this issue, and don' forget to add a testcase named into , then , git add the new and updated if any.
I resolved the issue with the submodule, is it alright if I claim this? It's a small patch to land. claim
Change:
<ins> // ICE regression relating to unconstrained lifetimes in implied // bounds. See #110161. // compile-flags: --crate-type=lib trait LtTrait { type Ty; } // erroneous `Ty` impl impl LtTrait for () { //~^ ERROR not all trait items implemented, missing: `Ty` [E0046] } // `'lt` is not constrained by the erroneous `Ty` impl<'lt, T> LtTrait for Box<T> where T: LtTrait<Ty = &'lt ()>, { type Ty = &'lt (); } // unconstrained lifetime appears in implied bounds fn test(_: <Box<()> as LtTrait>::Ty) {} fn test2<'x>(_: &'x <Box<()> as LtTrait>::Ty) {} </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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
See also , but while only reproduces with rustdoc, this one only repros with rustc and not rustdoc :thinking:
searched nightlies: from nightly-2023-01-01 to nightly-2023-04-11 regressed nightly: nightly-2023-03-29 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.6</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
claim I'll have a go at this, no idea if I'll be able to do it.
This is an ICE on invalid code. label regression-from-stable-to-nightly Minimized: this can be fixed by replacing the assertion with and returning early to avoid processing unconstrained lifetime variables in implied bounds. It would be nice if we have a comment referring to this issue or to the ui test for why delaying a bug was necessary.
btw, you should update your cargo-bisect-rustc to make it bisect the contents of rollups as well.
It is, unfortunately the regression is old enough that perf artifacts are gone :(
It's not old, but I remember now, this was my cursed rollup that didn't get unrolled perf builds. It also was a perf regression which made it pretty annoying :D
Change:
let path = Path::new(""); assert_eq!(path.canonicalize().unwrap_err().kind(), crate::io::ErrorKind::NotFound); } <ins> /// Ensure ReadDir works on large directories. /// Regression test for https://github.com/rust-lang/rust/issues/93384. #[test] fn read_large_dir() { let tmpdir = tmpdir(); let count = 32 * 1024; for i in 0..count { check!(fs::File::create(tmpdir.join(&i.to_string()))); } for entry in fs::read_dir(tmpdir.path()).unwrap() { entry.unwrap(); } } </ins>

Discussion:
runner: x8664-gnu-llvm-12, ubuntu-20.04-xl Occured in multiple pr across CI: : : : : and others
Possibly this was ? Looking at what's been merged in the last day, that seems to be the most relevant thing
You mean it might have introduced a new miscompilation that made compiletest crash?
Maybe. Its also possible that there was some existing UB elsewhere that happened to get set off by this, don't really know. My observation just mostly comes from where the segfault is happening and what commits in the last day have touched nearby code
Why this even triggered? Looks unrelated, but still suspicious.
Those warnings are unrelated. I'll post a patch soon to fix it. EDIT:
Funny thing: been merged even with crashed compiletest: , how this works?
The comment by is about the CI run not the bors run.
Yes, it failed on PR check, not on check-all-platforms-and-merge. So fast approving PR, so it merged even with failed PR check :-(
can you try to revert that pr and see, will it fail or not on test?
Yeah, I can do that before the end of the day
Reverting didn't fix it. Its still very suspicious that this started right after that got merged though. I'll leave the branch up on my fork for a little in case anyone else wants to re-run things or something.
The issue appears to be caused by a copy of dirent made in . Only a part of the structure as described by is actually dereferenceable: Which was recently changed for Linux and Android in .
It sounds like reverting that PR would be a good first step, since the bugs it fixes look less critical to me given that diagnosis. (Of course, maybe there is a more forward-moving fix, but a revert seems like something we can merge with less caution). cc
I'll take a look. do you mean the part? I didn't expect but maybe it's possible.
Oh indeed that seems to happen all the time. One sec I'll put up a patch
Change:
<ins> fn main() {} const fn unsize(x: &[u8; 3]) -> &[u8] { x } //~^ ERROR unsizing casts are not allowed in const fn const fn closure() -> fn() { || {} } //~^ ERROR function pointers in const fn are unstable const fn closure2() { (|| {}) as fn(); //~^ ERROR function pointers in const fn are unstable } const fn reify(f: fn()) -> unsafe fn() { f } //~^ ERROR function pointers in const fn are unstable const fn reify2() { main as unsafe fn(); } //~^ ERROR function pointers in const fn are unstable </ins>

Discussion:
<short summary of the bugReturning from a const fn causes internal compiler error, with the message 'bad input type for cast'. I tried this code: Minimal example Original example I expected to see this happen: program compiles and prints 'Hello 1' or I get a compiler error. Instead, this happened: ICE
that gives the exact backtrace above.
Relavent code: The types here are and .
The actual bug would be here then, right?
Not quite sure, but the real bug is that we allow the keyword in const fn XD I already have a fix since yesterday, but the german bahn didn't give me electricity so my notebook died while tests were running
no ICE fix from the ICE? :p
Change:
#![feature(lang_items, unsafe_destructor)] #![feature(box_syntax)] #![feature(optin_builtin_traits)] <ins> // FIXME(#21363) remove `old_impl_check` when bug is fixed #![feature(old_impl_check)] </ins> #![allow(unknown_features)] #![feature(int_uint)] #[macro_use]

Discussion:
This code fails to compile: error message: A similar error occurs if is used instead of . However, if you comment out the for loop, the call to works just fine. I thought maybe it had something to do with auto-deref, so I tried dereferencing the iterator: but dumps core: I'm not sure, but this may be related to ? dumps core when I try too. version:
CC
I think the problem is worse than this; trait objects in general don’t seem to be being recognised as implementing their traits: All three fail:
I'm not sure this is a bug at all. You're pretty much asking for an automatic - I did come up with a & -based model that would kinda work for this and IIRC pointed out that object-safe traits would eventually qualify for this. We do have object safety now, so it might be doable, but I wouldn't bet on it making into 1.0. In the meanwhile, does work? If it doesn't, is it just the case of missing in a couple places?
This a particular case of . See comments over there. is leaning towards an opt-in syntax extension that handles the boiler plate code, instead of automatic s by the compiler.
ByRef for trait objects seems to hit the same llvm assertion: output:
Interesting. So if I have a value with type where is a trait, then we can't say that implements in the general case? (Assuming object safety.) So my guess is that can still call because of auto deref? Shouldn't that mean it can work with ? Maybe that is what is about... You have to explicitly deref a to use it in ? (Sorry for all the questions. I'm just confused!)
doing autoderef on the iterator in seems like something reasonable to have. looks like the compiler is mistakenly treating an unsized lvalue as an rvalue, in trans.
On Mon, Jan 12, 2015 at 01:33:08PM -0800, Andrew Gallant wrote: Actually, I believe it works with , but not with the other types.
Just thank you for this issue. It resolves all my problems perfectly!
Change:
assert_eq!(original, parsed); }); } <del> )* </del> <ins> )+ </ins> } <del> ) </del> <ins> }; </ins> } supported_targets! {

Discussion:
There are actually two different generally expected encodings of the host tuple and they're subtly different than what some might expect. For example, 'x8664-sun-solaris' should probably be x8664-pc-solaris. The reason for that is that the encoding schemes are actually: So while 'sparcv9-sun-solaris' is correct because Sun is the (historical) manufacturer of sparc CPUs, 'x8664-sun-solaris' is not, because the MANUFACTURER here is the manufacturer of the CPU not the operating system. There are special cases for this, for example 'x8664-apple-darwin', even though Apple doesn't make x8664 CPUs, but following gcc/clang conventions leads us to x8664-pc-solaris. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
/cc /cc
An interesting discrepancy here is that our target and the LLVM target currently don't match. I'm not sure whether we can/should change anything here for backwards compatibility reasons, though an alias seems fine.
Hi, can I take this issue up? Can someone give a hint on how to fix this? I am a rust beginner, interested in compilers. This would be my first contribution.
as far as I can tell, you should just be able to add a new line under: containing , and then add a new line under: containing: (Sorry for the delay: I only just saw your message.)
claim
I wonder how it's supposed to work? Only x86_64-sun-solaris continues work for me: This change make it harder for Mozilla Firefox to decide which target to use...
I think we may have to introduce some changes in to make rustc try to use the alias. I.e. should try to use the target . I haven't had time to look into what else needs to be changed.
Closing as a duplicate of
Change:
<ins> error: trailing semicolon in macro used in expression position --> $DIR/issue-84195-lint-anon-const.rs:8:14 | LL |     () => { 0; }; |              ^ ... LL |     let val: [u8; len!()] = []; |                   ------ in this macro invocation | note: the lint level is defined here --> $DIR/issue-84195-lint-anon-const.rs:5:9 | LL | #![deny(semicolon_in_expressions_from_macros)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ = warning: this was previously accepted by the compiler but is being phased out; it will become a hard error in a future release! = note: for more information, see issue #79813 <https://github.com/rust-lang/rust/issues/79813> = note: this error originates in a macro (in Nightly builds, run with -Z macro-backtrace for more info) error: aborting due to previous error </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. --After testing, it's this macro here: The semicolon in the third variant causes the error when used in a context such as: Note that prior to updating I was using , which did not error. This errors on Nightly and Stable, I tested both ( and both have the same result). Removing the semicolon causes the project to build fine and function as it did before updating. : This error is repeated over and over again before the notification saying to submit the bug report <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Assigning priority as discussed as part of the and removing . label -I-prioritize +P-medium
Can you share the original repository, or provide a self-contained reproduction of the issue?
here is one I got to error in the same way: I also noticed this warning that I believe I failed to include in the original issue: If I remove the semicolon, this warning does not show up, and the program works as expected.
Change:
<ins> // Copyright 2013-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. // ignore-android: FIXME(#10381) // ignore-lldb // compile-flags:-g // gdb-command:break 'no-debug-attribute.rs':32 // gdb-command:break 'no-debug-attribute.rs':38 // gdb-command:run // gdb-command:info locals // gdb-check:No locals. // gdb-command:continue // gdb-command:info locals // gdb-check:abc = 10 // gdb-command:continue #![allow(unused_variable)] fn function_with_debuginfo() { let abc = 10u; return (); // #break } #[no_debug] fn function_without_debuginfo() { let abc = -57i32; return (); // #break } fn main() { function_without_debuginfo(); function_with_debuginfo(); } </ins>

Discussion:
Right now debuginfo can only be turned on or off globally. Sometimes it would be good to be able to exclude only specific functions from debuginfo, especially when they trigger a bug in rustc's or LLVM's debuginfo handling (e.g. ). This way, one would be able to still mostly use debuginfo in the presence of (localized) debuginfo issues.
Change:
}; let match_stmt = { <del> let match_expr = P(self.expr_match( </del> <ins> let match_expr = self.expr_match( </ins> span, poll_expr, hir_vec![ready_arm, pending_arm], hir::MatchSource::AwaitDesugar, <del> )); self.stmt(span, hir::StmtKind::Expr(match_expr)) </del> <ins> ); self.stmt_expr(span, match_expr) </ins> }; let yield_stmt = { let unit = self.expr_unit(span); <del> let yield_expr = P(self.expr( </del> <ins> let yield_expr = self.expr( </ins> span, hir::ExprKind::Yield(P(unit), hir::YieldSource::Await), ThinVec::new(), <del> )); self.stmt(span, hir::StmtKind::Expr(yield_expr)) </del> <ins> ); self.stmt_expr(span, yield_expr) </ins> }; let loop_block = P(self.block_all(

Discussion:
See:
for future reference: is referencing my PR which changed the r-value temporary rules with respect to the temporaries in the of
Even beside the part the loop desugaring is so complex. It would be nice to document what every employed trick changes compared to the naive desugaring.
PR itself was motivated (or at least spawned off of) PR . I'm actually trying to find out what the actual motivation for the described change was. The change, as described, was that the temporaries within would previously live until the end of the enclosing block. So if you consider the following code (): which, when it is accepted by the compiler (as written it requires NLL), it should print this: notably, we drop all of {, , } immediately after the for-statement, but before the at the end of the block. The breakage I would be concerned about, if we made for-loops no longer a terminating scope for their , is that all of the temps would live until the end of the block, and thus the drops of {, , } would happen after the "end of enclosing block", which would be an observable change. has relayed to me in private conversation that they tried examples like this under variants of their desugaring and did not witness any change in behavior. Our best guess as to why this is, is because the desugaring is, in the end, turning into a which is itself a terminating scope for the temporaries in the -input, and so you don't need to recreate such an effect by other means.
Note: it is nonetheless possible that the distinction here is more subtle and my above example isn't quite right. in particular, I'm a little worried that there may have been a reason that the example from PR puts the for-expression in the tail expression of a block, and that examples that don't take similar care might fail to pick up on a relevant distinction here...
Change:
of_trait: Some(trait_ref), .. }) = item.kind <ins> && let Some(def_id) = trait_ref.trait_def_id() </ins> { <del> let def_id = trait_ref.trait_def_id().unwrap(); </del> let source_map = tcx.sess.source_map(); if !tcx.has_attr(def_id, sym::const_trait) { tcx.sess

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. --code from <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
couple of files from the repo that reproduce this: ./src/test/ui/rfc-2632-const-trait-impl/staged-
This regressed in cc
Thanks for the bisection. This should be a simple fix: Replace with And add a test as well :) label E-easy
claim
Are you still working on this? If not, I would like to fix this as soon as possible.
Sorry for the delay, no problem. Thanks.
Change:
Float(f) => cast_const_float(tcx, f, ty), Char(c) => cast_const_int(tcx, Infer(c as u64), ty), Function(_) => Err(UnimplementedConstVal("casting fn pointers")), <ins> ByteStr(_) => match ty.sty { ty::TyRawPtr(_) => { Err(ErrKind::UnimplementedConstVal("casting a bytestr to a raw ptr")) }, _ => Err(CannotCast), }, </ins> _ => Err(CannotCast), } }

Discussion:
In particular, . We can't use because it's in a const context.
whoops, on it
Please reopen.
hmm... that's a different issue. this looks like your new constant code
Change:
<ins> #![feature(let_chains)] //~ WARN the feature `let_chains` is incomplete fn main() { if true && let x = 1 { //~ ERROR `let` expressions are not supported here let _ = x; } } </ins>

Discussion:
I tried this code: : Note: A simpler program does not crash, but does not compile.
Is it possible for you to share the code?
It might be better for you to share the code which reproduces the issue on your nightly, 2021-02-11, so that I can try to reproduce it on the latest nightly build and possibly find the commit that might have introduced this issue.
Okay, I'll trim down my base and share it later today.
I deleted my whole project and got this
Thanks label: -E-needs-mcve
Not sure if this helps: I ran on my host target , and it is shown that it ICEd back in 2018 (even before the initial implementation of the feature.
Duplicate of
Change:
h.finish() //~ ERROR no method named `finish` found for struct `DefaultHasher` } <del> fn main() {} </del> <ins> trait Bar {} impl Bar for String {} fn main() { let s = String::from("hey"); let x: &dyn Bar = &s; x.as_ref(); //~ ERROR the method `as_ref` exists for reference `&dyn Bar`, but its trait bounds } </ins>

Discussion:
Given the following code (): The output on is: <details<summaryLong diagnostic</summary</details, , , and are suggested three times each: once for , once for , and once for . I'm not sure if this is a problem, but this seems incredibly verbose to me. Note that the output on stable 1.51 and beta 1.52 is different:
My mistake, each repetition is actually different in that two suggest taking a reference to : This still seems like a fairly massive diagnostic, though. I've updated the original post in light of this. Feel free to close if a diagnostic of this size is fine here.
cc
Might be a duplicate of , or at least fixed by the same PR that fixed it
Even if it was considered reasonable to suggest each and every possible type combination, there is no pressing reason for it to generate the intervening lines as well: rustc is a compiler, not a can of spam. This remains unpatched on nightly, and is thus a stable-to-beta diagnostic regression.
AFAICT, this is not present on beta, and is only present on nightly, so it's a stable-to-nightly regression. Please correct me if I misunderstood!
searched nightlies: from nightly-2021-01-01 to nightly-2021-04-24 regressed nightly: nightly-2021-04-09 searched commits: from to regressed commit: That is: so it’s . I guess has already been mentioned. label D-verbose
Yes, yes, I introduced this regression. Mea culpa, everybody. In my defense I keep flip-flopping between being too restrictive and too permissive for new suggestions and someone always ends up getting the short end of the stick. This week, I'm leaning towards "too permissive" and if the suggestion triggers too often, then detect the cases and make it more constrained, because the alternative is that the suggestion isn't shown when it could, and we'll never find out. This is IMO better, as long as regressions are caught in nightly, like it was in this case.&lt;/rantAnyways, fixes this.
Assigning and removing .
This now affects 1.53.0 beta. Updating the labels accordingly.
Still needs to be backported.
the beta backport for patch was approved, can this now be closed?

I think we should wait until it actually lands onto beta
This was merged in beta already, right?
Ah, so it was.