jiebi/CodeConvo huggingface dataset:
Change:
<ins> warning: anonymous parameters are deprecated and will be removed in the next edition --> $DIR/issue-89280-emitter-overflow-splice-lines.rs:4:21 | LL |       fn test(x: u32, ( |  _____________________^ LL | | LL | | LL | |     )) {} | |_____^ | = note: `#[warn(anonymous_parameters)]` on by default = warning: this is accepted in the current edition (Rust 2015) but is a hard error in Rust 2018! = note: for more information, see issue #41686 <https://github.com/rust-lang/rust/issues/41686> help: try naming the parameter or explicitly ignoring it | LL ~     fn test(x: u32, _: ( LL + LL + LL ~     )) {} | warning: 1 warning emitted </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. --Rebase over , then run . I think this is the test. cc but I think this is an issue with rustcerrors, not clippy itself. <!-- 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
This is from a diagnostic constructed in a pre-expansion pass. Maybe this has something to do with the ICE
I'm able to reproduce this by running with the following contents: And it needs .
I thought this had been solved by a recent PR :(
No, I just avoided a malformed span that was hitting the same ICE The ICE itself will occur for any multi line span where the end is to the left of the start:
Change:
<ins> // check-pass // Make sure we don't have any false positives about the "struct is never constructed" lint. #![deny(dead_code)] struct Foo { #[allow(dead_code)] inner: u32, } impl From<u32> for Foo { fn from(inner: u32) -> Self { Self { inner } } } fn main() {} </ins>

Discussion:
Consider the following code snippet: This will trigger a 'struct is never constructed' warning, even though the struct is clearly constructed in the implementation of . The problem seems to be caused by using as the constructor. If I replace with the name of the struct, as in the following code snippet, the warning goes away:
You seem to have posted the same snippet twice
My bad! I've updated my comment.
I think this is because is not public, and so rustc can see that that trait implementation is never used. If you make it , the warning goes away. (With a new warning about inner never being used, which is also true, and if you make that , you get no warnings)
That seems reasonable, but in that case, I'd expect to get a warning if is private, regardless of whether I instantiate it with or in the implementation of . As it stands, I only get a warning if I instantiate it with , which seems inconsistent?
This also happens with enum variants and "variant is never constructed" warning, see .
This also applies in connection with : I get warnings about and although they are clearly used multiple times in my code. But maybe I'm doing something wrong here or getting it wrong as a concept in my head; if so, I'm glad for some pointers and hints :-)
None of the incorrect warnings are emitted anymore (nightly 2023-01-22). label: +E-needs-test
Change:
<ins> #[derive(Clone)] struct S; trait X {} impl X for S {} fn foo<T: X>(_: T) {} fn bar<T: X>(s: &T) { foo(s); //~ ERROR the trait bound `&T: X` is not satisfied } fn bar_with_clone<T: X + Clone>(s: &T) { foo(s); //~ ERROR the trait bound `&T: X` is not satisfied } fn main() { let s = &S; bar(s); } </ins>

Discussion:
we should suggest cloning. Also, we should suggest <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
If we suggest add bound, we don't need dervie , This code will compile:
Change:
}); (present_variants.next(), present_variants.next()) }; <del> if present_first.is_none() { </del> <ins> let present_first = match present_first { present_first @ Some(_) => present_first, </ins> // Uninhabited because it has no variants, or only absent ones. <del> return tcx.layout_raw(param_env.and(tcx.types.never)); } </del> <ins> None if def.is_enum() => return tcx.layout_raw(param_env.and(tcx.types.never)), // if it's a struct, still compute a layout so that we can still compute the // field offsets None => Some(VariantIdx::new(0)), }; </ins> let is_struct = !def.is_enum() || // Only one variant is present.

Discussion:
This ICEs on stable, probably since March 2018, but it requires the user to do UB in constants, so... I think a possible fix would be to enable validation in const eval (cc ), though we should benchmark the perf considerations around that first. Alternatively we can just not ICE here and instead emit an error. () Errors:
Interesting. ICEs in Miri with are also bugs, so I'd say doing more validation is not the right call. Do you have a backtrace? Which code is responsible for ICEing here and how hard/bad would it be to just error instead?
It's ICEing in and we could indeed just emit a UB error here, but it seems very... odd, since the field access check has very little to do with UB at a first glance. The layout is a union with zero fields, because it's essentially .
TBH this looks like a bug to me. That's the layout of which type, ? It should have a field, and it should not be a union. Cc
It's not a bug. Just like layout for a newtype with a single field is not a bug (E.g. ).
Precisely by analogy with , I think this is a bug. Your has a with exactly 1 field, matching what is declared. It does not have 2 fields which would be the case if it had a "pair layout". So, transparent layout changes the , but it does not change how many "fields" a type is considered to have. Similarly, has 3 fields in its layout, despite still being a . So, correspondingly, should have 1 field.
oh... right. Yea we should totally fix that
This being a layout bug would trivially break codegen, why is only miri affected?
Codegen might skip the field access because the type is uninhabited?
I wouldn't be so sure, codegen calls on layouts a lot without checking. Can the ICE print the whole ? That might be more useful here. EDIT: oh this might be why: we don't check the index at all:
yea but we can't use because that ICEs during const prop in the array case. I have a local branch that I'm playing with to get the entire picture
You can literally remove the assert to get the same effect.

But if the field count is wrong I'd rather have an assert in both places and fix the count (if possible).
The full is and so far I haven't figured out how that can happen
Ah, nevermind, I found it:
Ah so that's a micro-optimization. Maybe we should compute the right thing.
computes the layout for structs but keeps returning the never layout for enums without inhabited variants
Change:
<ins> // test for #122098 ICE snapshot_vec.rs: index out of bounds: the len is 4 but the index is 4 trait LendingIterator { type Item<'q>: 'a; //~^ ERROR use of undeclared lifetime name `'a` fn for_each(mut self, mut f: Box<dyn FnMut(Self::Item<'_>) + 'static>) {} //~^ ERROR the size for values of type `Self` cannot be known at compilation time } struct Query<'q> {} //~^ ERROR lifetime parameter `'q` is never used impl<'static> Query<'q> { //~^ ERROR invalid lifetime parameter name: `'static` //~^^ ERROR use of undeclared lifetime name `'q` pub fn new() -> Self {} } fn data() { LendingIterator::for_each(Query::new(&data), Box::new); //~^ ERROR this function takes 0 arguments but 1 argument was supplied } pub fn main() {} </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at /rust/deps/ena- 'index out of bounds: the len is 4 but the index is 4'', 'thread 'rustc' panicked at /rust/deps/ena- 'index out of bounds: the len is 4 but the index is 4'' File: --snippet: 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 --
Regression in cc
Wow we leak an infer var out of the rollback scope that declared it
WG-prioritization assigning priority (). label -I-prioritize +P-medium
probably fixed by

<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'begin <= end (6 <= 5) when slicing '', 'thread 'rustc' panicked at 'begin <= end (6 <= 5) when slicing '' File: --snippet: 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: [mirborrowck] borrow-checking [analysis] running analysis passes on this crate --
cc
Change:
<ins> // check-pass // edition:2018 // compile-flags: --crate-type=lib pub async fn test() { const C: usize = 4; foo(&mut [0u8; C]).await; } async fn foo(_: &mut [u8]) {} </ins>

Discussion:
Sorry for the vague title. () <details<summaryRelevant errors:</summary</details<hrNote that this does not result in an ICE: Also works with shared references. <hr
Regression in – 1.44.0-nightly ( 2020-03-24) Commits:
This needs bisection ping cleanup
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
I suspect based on .
Assigning and removing nomination. This was .
Oops, forgot to cc
I just tried to repro in our test suite and passes... This is on unmodified master from 03:00 this morning.
Oh interesting, this only reproduces with , probably because the function is then never really compiled because it's dead code. The following also ICEs
found a fix, not sure if that is too ad-hoc though.
Change:
_ => ret.push(panictry!(parser.parse_impl_item())) } } <del> self.ensure_complete_parse(false); </del> <ins> self.ensure_complete_parse(false, "item"); </ins> Some(ret) }

Discussion:
This compiles: I expected this to be rejected, simply because doesn't parse as a type.

afaik, it's because the context where you're using the macro (expr, item, etc.) stopped parsing before that token. We should mention that context.
Is this fixed? I think this was fixed the referenced pull request.
I'd prefer a message like
Change:
paths } <del> /// Copies a file from `src` to `dst` and doesn't use links, so /// that the copy can be modified without affecting the original. pub fn really_copy(&self, src: &Path, dst: &Path) { if self.config.dry_run { return; } self.verbose_than(1, &format!("Copy {:?} to {:?}", src, dst)); if src == dst { return; } let _ = fs::remove_file(&dst); let metadata = t!(src.symlink_metadata()); if let Err(e) = fs::copy(src, dst) { panic!("failed to copy `{}` to `{}`: {}", src.display(), dst.display(), e) } t!(fs::set_permissions(dst, metadata.permissions())); let atime = FileTime::from_last_access_time(&metadata); let mtime = FileTime::from_last_modification_time(&metadata); t!(filetime::set_file_times(dst, atime, mtime)); } </del> /// Copies a file from `src` to `dst` pub fn copy(&self, src: &Path, dst: &Path) { if self.config.dry_run {

Discussion:
Since we run cargo vendor unconditionally to vendor libtest in libstd. We should either pass it '--offline' or add a way to conditionally do so to avoid using network when unnecessary
I am happy to accept a patch for this; if it is not small (e.g., just adding offline) we will likely end up wanting to revert on beta.
Is this really P-critical? I would think this is P-high since P-critical is usually reserved for severe user-facing bugs.
I consider inability for distros to build a particular version of Rust to be a release blocker.
Here what i've tried so far: - - None of those worked out, last failure:
With just the (without the generate-lockfile):
Ah, I didn't realize it was that bad! Sorry about that.
cc -- do we expect cargo vendor to work without network when vendoring a subset of a workspace? It looks like we're running into some trouble here to get it working, though I've not personally had time yet to test. cc as well
I believe Cargo is working as intended here, when you run in the workspace root it doesn't actually vendor the crates from because they're patched locally to the in-tree versions. Then when Cargo later vendors for libtest, it doesn't see the annotations so it tries to download them from the network. If you've passed and you're using a vendor directory that means Cargo can't download any more packages, so it provides this error. I think the fix here is to either get Cargo to see the for these crates during the libtest vendoring process or somehow get those crates vendored in whatever does the original vendor.
Will give the approach a try, thanks a lot for the explanation edit: assuming adding the patch section to e.g. libtest can work
I have posted a revert for the current release () since there were several issues on the Cargo side, too. Hopefully we'll try to avoid these issues when we try again.
Change:
let entry = spanned_predicates.entry(spans); entry.or_insert_with(|| (path, tr_self_ty, Vec::new())).2.push(p); } <ins> Some(Node::Item(hir::Item { kind: hir::ItemKind::Trait(rustc_ast::ast::IsAuto::Yes, ..), span: item_span, .. })) => { tcx.sess.delay_span_bug( *item_span, "auto trait is invoked with no method error, but no error reported?", ); } </ins> Some(_) => unreachable!(), None => (), }

Discussion:
Found with a error]: auto traits cannot have associated items thread 'rustc' panicked at 'internal error: entered unreachable code', <details<summaryFull output including backtrace</summary</detailsRegression in nightly-2022-11-05, somewhere in rollup , likely (CC 2022-12-14 label +F-autotraits <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Fixed the ICE, the error message now is: I think the second error message should not come out, considering the is an auto trait.
Change:
ast_generics: &ast::Generics, abis: AbiSet) -> ty::ty_param_bounds_and_ty { <ins> for i in decl.inputs.iter() { match (*i).pat.node { ast::PatIdent(_, _, _) => (), ast::PatWild => (), _ => ccx.tcx.sess.span_err((*i).pat.span, "patterns aren't allowed in foreign function declarations") } } </ins> let ty_generics = ty_generics(ccx, ast_generics, 0); let rb = BindingRscope::new(def_id.node); let input_tys = decl.inputs .iter() .map(|a| ty_of_arg(ccx, &rb, a, None)) .collect(); let output_ty = ast_ty_to_ty(ccx, &rb, decl.output); let t_fn = ty::mk_bare_fn(

Discussion:
The following compiles fine, but uncommenting any of the currently-commented functions makes the compiler ICE. For the ICE message is and the others are similar.
I'm inclined to say that the correct behavior is to deny all patterns other than (give a parser error perhaps).
Nominating.
I agree
Accepted for 1.0, P-backcompat-lang.
Good newbie bug.
Being a good newbie, I'll have a crack at this one. :)
Might have aimed a little too high by trying this issue.. but from what i understand, the type checking is working as people would like, but the message is incorrect and should be a actual syntax error and not an ICE... so the below is some thing like how it should work? Sorry if I've completely misunderstood, still pretty nubbins with Rust. :
my reading of is that all of your examples should fail; ideally only an identfier should pass.
They should all fail, the only thing that should pass is , nothing involving destructuring or pattern matching. One way to implement this would be to make it an actual syntax error. You can find a starting place for this change by grepping for in . (I personally would recommend implementing this by threading a argument through , to where you chose between the existing call and calling directly based on that boolean.)
Ahhh okay, that makes more sense. Thanks for that. I'll see what I can make happen.
Change:
``` ", $Feature, "assert_eq!(100", stringify!($SelfT), ".saturating_sub(127), -27); assert_eq!(", stringify!($SelfT), "::min_value().saturating_sub(100), ", stringify!($SelfT), <del> "::min_value());", </del> <ins> "::min_value()); assert_eq!(", stringify!($SelfT), "::max_value().saturating_sub(-1), ", stringify!($SelfT), "::max_value());", </ins> $EndFeature, " ```"), #[stable(feature = "rust1", since = "1.0.0")]

Discussion:
Godbolt link: So I expect these two functions has the same assembly: But the result is not:
modify labels: -C-bug -I-slow T-compiler
Hey I tried solving this but wasn't really sure how to. I believe the implementation to the LLVM generation is right here. Hope someone can solve this!
Turn out I was wrong! The is working correctly (i.e. those two functions are not equivalent): I would add some doctests to show that and close this issue.
Change:
) if ns == ValueNS => { bad_struct_syntax_suggestion(def_id); } <ins> (Res::Def(DefKind::Ctor(_, CtorKind::Const), def_id), _) if ns == ValueNS => { match source { PathSource::Expr(_) | PathSource::TupleStruct(..) | PathSource::Pat => { let span = find_span(&source, err); if let Some(span) = self.def_span(def_id) { err.span_label(span, &format!("`{}` defined here", path_str)); } err.span_suggestion( span, &format!("use this syntax instead"), format!("{path_str}"), Applicability::MaybeIncorrect, ); } _ => return false, } } </ins> (Res::Def(DefKind::Ctor(_, CtorKind::Fn), def_id), _) if ns == ValueNS => { if let Some(span) = self.def_span(def_id) { err.span_label(span, &format!("`{}` defined here", path_str));

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. -- The current output is: Ideally the output should look like: I'd like it to say "try to use a unit variant like "FarmAnimal::Cow" instead". For example, here's what happens if you use Tuple syntax instead of Struct syntax: So I'd like the new diagnostic to look something 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 is an example Ferrous Systems uses in our trainings, and some of our participants have tripped over this lack of suggestion here. The compiler DOES provide diagnostics when you use a struct syntax instead of a tuple syntax.
Alternatively the help could suggest a more direct: "Remove the parenthesis here".
claim
I just wanted to mention , and I wanted to thank you personally for implementing this diagnostics improvement so quickly! Let me know if you have a blog or twitter you'd like us to link to (rather than your GH profile).
Hello, linking to my GH profile is fine. I did not know I would contribute to such an interesting learning experience. Anyway thank you for mentioning me in your blog post .
Change:
LL |     (5) |     ^^^ help: remove these parentheses <ins> error: unnecessary parentheses around assigned value --> $DIR/lint-unnecessary-parens.rs:41:27 | LL | const CONST_ITEM: usize = (10); |                           ^^^^ help: remove these parentheses error: unnecessary parentheses around assigned value --> $DIR/lint-unnecessary-parens.rs:42:29 | LL | static STATIC_ITEM: usize = (10); |                             ^^^^ help: remove these parentheses </ins> error: unnecessary parentheses around function argument <del> --> $DIR/lint-unnecessary-parens.rs:43:9 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:46:9 </ins> | LL |     bar((true)); |         ^^^^^^ help: remove these parentheses error: unnecessary parentheses around `if` condition <del> --> $DIR/lint-unnecessary-parens.rs:45:8 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:48:8 </ins> | LL |     if (true) {} |        ^^^^^^ help: remove these parentheses error: unnecessary parentheses around `while` condition <del> --> $DIR/lint-unnecessary-parens.rs:46:11 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:49:11 </ins> | LL |     while (true) {} |           ^^^^^^ help: remove these parentheses warning: denote infinite loops with `loop { ... }` <del> --> $DIR/lint-unnecessary-parens.rs:46:5 </del> <ins> --> $DIR/lint-unnecessary-parens.rs:49:5 </ins> | LL |     while (true) {} |     ^^^^^^^^^^^^ help: use `loop`

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:
/// /// let p: *mut i32 = ptr::null_mut(); /// assert!(p.is_null()); <ins> /// assert_eq!(p as usize, 0); // this pointer has the address 0 </ins> /// ``` #[inline(always)] #[must_use]

Discussion:
This has come up in two places recently: and We should do the following: On , document that is equivalent to Either before or after it lands, update the text in to document that "allocated objects" cannot contain the 0 address (alternatively, if that PR lands with text that says that an allocated object cannot contain the "null" address, update the text to mention that null is equal to 0) Are there other places we should update too? cc
there was some discussion in https://rust-
Int-to-ptr casts are terrible, I'd rather not do that. In fact these two are not equivalent for Miri (but that might be a Miri limitation, int2ptr is just hard or impossible to handle precisely for a tool like Miri). We should say that it returns a pointer whose address is 0, but we shouldn't commit to which provenance it has.
adds the docs for this.
Change:
<ins> // compile-pass union Uninit { _never_use: *const u8, uninit: (), } const UNINIT: Uninit = Uninit { uninit: () }; fn main() {} </ins>

Discussion:
It looks like this was broken in the release of 1.32.0 (and is still broken, even on nightly) (checked on ). The following example program: Fails to compile: Interestingly, making the fixes it. My Rust version: I know , but I don't think this qualifies as a field access. And yes, I'm aware of . cc
Interesting. Looks like a validation issue? Cc