jiebi/CodeConvo huggingface dataset:
Code change:
<ins> error: this file contains an un-closed delimiter --> $DIR/issue-58094-missing-right-square-bracket.rs:4:4 | LL | #[Ѕ |  - ^ |  | |  un-closed delimiter error: expected item after attributes --> $DIR/issue-58094-missing-right-square-bracket.rs:4:4 | LL | #[Ѕ |    ^ error: aborting due to 2 previous errors </ins>

Related discussion:
text: I realize it's kinda nonsensical, but here:
Why didn't WF catch this?
That's because only checks statics/constants.
Still reproducible with .
This ought to be a mostly easy fix. The problem is that the well formedness check, which ought to be rejected this code, is ignoring things in an : They fall through to this `` case: We would need to add support for the HIR item: which in turn has a number of items: which are defined here: presumably we want the to check that the types of are well-formed, roughly analogous to how we current check normal static items: (We probably want similar checks on foreign item fns, though?) One tricky part might be compatibility, we may need to turn this into a compatibility lint in case there is lots of broken code in the wild.
I am trying to fix this bug, and need help moving forward. function is modified to accept a and a , yet it doesn't report any additional errors and the ICE prevails. Test file: Commit: Should I create a pull request or is it too early?
Looks like suggestions are incomplete ( does not require ). Also, I left a comment on your commit about how you can avoid adding . I suspect the only reason regular s are required to be is they have an initializer (and that, not the type, requires ), i.e. for we have these errors:
Oddly, the PR that were previously posted to fix this (PR , following on PR ) was subsequently closed as inactive ... but the bug itself seems like it may have been resolved in the meantime?
I'm going to assume this was fixed. Tagging as E-needstest, but if someone wants to take the time, it'd be even better to bisect to where this was fixed, and see if a regression test for this was at that time.
Compiler no longer panics, tested with
Code change:
} } <ins> impl rustc_errors::IntoDiagnosticArg for PolyExistentialTraitRef<'_> { fn into_diagnostic_arg(self) -> rustc_errors::DiagnosticArgValue<'static> { self.to_string().into_diagnostic_arg() } } </ins> #[derive(Copy, Clone, PartialEq, Eq, PartialOrd, Ord, Hash, Debug, TyEncodable, TyDecodable)] #[derive(HashStable)] pub enum BoundVariableKind {

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. --ICE with in I just noticed the error actually says openpgp-card at the bottom, perhaps compilation doesn't even get to the final crate. In any case, I'm no good at minimizing these things, so I'm handing this off to people who are good at that. <!-- 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 label +E-needs-mcve
searched nightlies: from nightly-2023-01-01 to nightly-2023-01-15 regressed nightly: nightly-2023-01-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
This fixes the ICE, although I'm not sure if that's the right approach
label -E-needs-mcve
Code change:
} let sig = tcx.erase_late_bound_regions(sig); <del> if !sig.output().is_unit() { let r = self.check_type_for_ffi(cache, sig.output()); match r { FfiSafe => {} _ => { return r; } } } </del> for arg in sig.inputs() { <del> let r = self.check_type_for_ffi(cache, *arg); match r { </del> <ins> match self.check_type_for_ffi(cache, *arg) { </ins> FfiSafe => {} <del> _ => { return r; } </del> <ins> r => return r, </ins> } } <del> FfiSafe </del> <ins> let ret_ty = sig.output(); if ret_ty.is_unit() { return FfiSafe; } self.check_type_for_ffi(cache, ret_ty) </ins> } ty::Foreign(..) => FfiSafe,

Related discussion:
text: The function itself is considered FFI-safe and does not trigger the warning (). Its function pointer should also be allowed, to be consistent. Discovered on CI The original code has several more levels of indirection, but is also considered FFI-safe before. <details<summaryExtracted original code</summary</detailsAccording to CI logs, the warning occurs since rust 1.72.0-nightly ( 2023-07-03). Probably caused by . cc
Okay, so, I had a fix for this that just got rid of the regression, but I'm not sure that's the correct solution here - I think this is correct to be linting in the fn-ptr case and should be linting for the function case. is FFI-unsafe, but we allow a function to return because that's the default, but that doesn't mean that a within a type is okay (with the exception of a wrapper around the - because that's just returning , which we've already decided is okay). In the function case that works right now, that's being allowed because of this code.. ..which is there to support the case. However, it's not quite the right check. It doesn't actually check for ! It checks that the type - however nested - which was deemed FFI-unsafe is and that type is part of a return type. So any FFI-unsafe in a return type makes the entire return type FFI-safe - which is clearly incorrect. That's making the example below compile, which absolutely shouldn't. I've submitted , which makes this even more of a regression by making the function case fail too. We already had a simple "is it a unit" check, so I extended that to check for transparent newtype wrappers too, and removed the incorrect check.
This is unfortunate since I'm trying to return a where is likely to be . What should I do instead if I want to be FFI-safe with layout ?
I'm not so sure anymore after reading comment (). It's clear that some changes are required regardless - our current implementation wrong as demonstrated in the final example from my previous comment, but it's also inconsistent, in that this example... lint for the argument use of , but not the return use of , when really it should be both or neither. After my pull request, it's both.
Code change:
} let sig = tcx.erase_late_bound_regions(sig); <del> if !sig.output().is_unit() { let r = self.check_type_for_ffi(cache, sig.output()); match r { FfiSafe => {} _ => { return r; } } } </del> for arg in sig.inputs() { <del> let r = self.check_type_for_ffi(cache, *arg); match r { </del> <ins> match self.check_type_for_ffi(cache, *arg) { </ins> FfiSafe => {} <del> _ => { return r; } </del> <ins> r => return r, </ins> } } <del> FfiSafe </del> <ins> let ret_ty = sig.output(); if ret_ty.is_unit() { return FfiSafe; } self.check_type_for_ffi(cache, ret_ty) </ins> } ty::Foreign(..) => FfiSafe,

Related discussion:
text: With and without my pull request, when you change this to , it doesn't lint.
I'll nominate this issue so that it sees some discussion - see also and .
I posted some more info on zulip but it may also worth mentioning here. ZST is still zero-sized under repr(C), rather than FFI-unsafe.
The issue now also exists in beta. I also found uitests which seems to expect ZST to be FFI-safe, but ends in to suppress the warning and tests nothing.
We discussed this in today's meeting. We didn't have consensus that this should warn; at least some people thought the code in the top comment should continue to compile without warnings. We did have consensus that changing that (to warn) would need an FCP. So, we felt that we'd like to see a fix removing the warning applied to beta and nightly, and then separately if someone wants to propose that we change this to warn, we could evaluate that and do an FCP on it. But at the moment the temperature of the team seems to be that we don't have consensus for such an FCP.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
labels -I-lang-nominated We rendered our opinion
Code change:
.filter_map(|lang_item| self.tcx.lang_items().require(*lang_item).ok()) .collect(); <del> never_suggest_borrow.push(self.tcx.get_diagnostic_item(sym::Send).unwrap()); </del> <ins> if let Some(def_id) = self.tcx.get_diagnostic_item(sym::Send) { never_suggest_borrow.push(def_id); } </ins> let param_env = obligation.param_env; let trait_ref = poly_trait_ref.skip_binder();

Related discussion:
text: I came across this while working on . Sadly I wasn't really able to minimize this. this branch: and go to (but other commits will likely work too). to and paste in the following:
See also
Slightly minimized: place in Then run: will produce the ICE.
Caused by , cc That PR renames a lot of diagnostic items, but didn't use to gate the name change, so causes breakage when compiling stage 0 std or stage 1 compiler.
Oops, sorry!
Code change:
continue; } <del> let missing = match source { PathSource::Trait(..) | PathSource::TraitItem(..) | PathSource::Type => true, </del> <ins> let node_ids = self.r.next_node_ids(expected_lifetimes); self.record_lifetime_res( segment_id, LifetimeRes::ElidedAnchor { start: node_ids.start, end: node_ids.end }, LifetimeElisionCandidate::Ignore, ); let inferred = match source { PathSource::Trait(..) | PathSource::TraitItem(..) | PathSource::Type => false, </ins> PathSource::Expr(..) | PathSource::Pat | PathSource::Struct <del> | PathSource::TupleStruct(..) => false, </del> <ins> | PathSource::TupleStruct(..) => true, </ins> }; <del> if !missing && !segment.has_generic_args { </del> <ins> if inferred { // Do not create a parameter for patterns and expressions: type checking can infer // the appropriate lifetime for us. for id in node_ids { self.record_lifetime_res( id, LifetimeRes::Infer, LifetimeElisionCandidate::Named, ); } </ins> continue; }

Related discussion:
text: This code: compiles on stable but not on nightly. Error: I bisected it to and then refined it; reverting fixes the issue. This is the cause for
ping since you're the author of the commit
WG-prioritization assigning priority (). label -I-prioritize +P-critical
note: there's a fix in ready for review
Code change:
move_place: &Place<'tcx>, deref_target_place: &Place<'tcx>, span: Span, <ins> use_spans: Option<UseSpans>, </ins> ) -> DiagnosticBuilder<'a> { // Inspect the type of the content behind the // borrow to provide feedback about why this

Related discussion:
text: gives the error: Error0507 gives a wrong suggestion here:
Error: Label D-invalid-suggestion can only be set by Rust team members Please let know if you're having trouble with this bot.
modify labels: A-suggestion-diagnostics C-bug T-compiler
Code change:
<ins> // compile-flags: -Znext-solver #![feature(lazy_type_alias)] //~^ WARN the feature `lazy_type_alias` is incomplete trait Foo {} type A<T: Foo> = T; struct W<T>(T); // For `W<A<usize>>` to be WF, `A<usize>: Sized` must hold. However, when assembling // alias bounds for `A<usize>`, we try to normalize it, but it doesn't hold because // `usize: Foo` doesn't hold. Therefore we ICE, because we don't expect to still // encounter weak types in `assemble_alias_bound_candidates_recur`. fn hello(_: W<A<usize>>) {} //~^ ERROR the type `W<A<usize>>` is not well-formed fn main() {} </ins>

Related discussion:
text: <!-- [31mICE[0m: Rustc '-Znext-solver=coherence -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'internal error: entered unreachable code: Weak and Inherent aliases should have been normalized away already'', 'thread 'rustc' panicked at 'internal error: entered unreachable code: Weak and Inherent aliases should have been normalized away already'' 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: [specializationgraphof] building specialization graph of trait [coherent_trait] coherence checking all impls of trait [analysis] running analysis passes on this crate --
cc
Code change:
<ins> // Copyright 2015 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. fn main() { let mut c = (1, "".to_owned()); match c { c2 => { c.0 = 2; assert_eq!(c2.0, 1); } } } </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:
<del> error: expected expression, found reserved keyword `try` --> $DIR/try-block-in-while.rs:6:11 </del> <ins> error[E0277]: the trait bound `bool: std::ops::Try` is not satisfied --> $DIR/try-block-in-while.rs:6:15 </ins> | LL |     while try { false } {} <del> |           ^^^ expected expression </del> <ins> |               ^^^^^^^^^ the trait `std::ops::Try` is not implemented for `bool` | = note: required by `std::ops::Try::from_ok` </ins> error: aborting due to previous error <ins> For more information about this error, try `rustc --explain E0277`. </ins>

Related discussion:
text: This produces a lint: But removing the parentheses produces an error. This bug was already mentioned in , but that issue is lost in feature-request purgatory since it asks for the version without parentheses to be allowed. I'm opening this issue to track the incorrect lint specifically. (Edit: Fixed the example.) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim Will wait for to get merged before this is fixed though.
Code change:
<del> error: expected expression, found reserved keyword `try` --> $DIR/try-block-in-while.rs:6:11 </del> <ins> error[E0277]: the trait bound `bool: std::ops::Try` is not satisfied --> $DIR/try-block-in-while.rs:6:15 </ins> | LL |     while try { false } {} <del> |           ^^^ expected expression </del> <ins> |               ^^^^^^^^^ the trait `std::ops::Try` is not implemented for `bool` | = note: required by `std::ops::Try::from_ok` </ins> error: aborting due to previous error <ins> For more information about this error, try `rustc --explain E0277`. </ins>

Related discussion:
text: The following code fails to compile (): The compiler error is: Adding parentheses or braces, it will compile fine: The same issue happens with other constructs such as:
cc
I believe the error is expected here, the same as with : Which also needs to be to compile. That said, the warning to remove the necessary parens is definitely wrong. EDIT: Hmm, I might be wrong, actually. The following compiles, which surprised me: as does this: So maybe the parser restriction is only for struct literals, not for keyword-introduced expressions.
Yeah I think is the better comparison here so it's probably a bug.
This is exactly what a thought. I didn't know that this:
For , hmmm... well, I can't come up with a truly devastating example, but eliminating the parentheses could hurt diagnostics.
Code change:
.iter() .enumerate() .filter(|x| x.1.hir_id == *hir_id) <del> .map(|(i, _)| init_tup.get(i).unwrap()) .next() </del> <ins> .find_map(|(i, _)| init_tup.get(i)) </ins> { self.note_type_is_not_clone_inner_expr(init) } else {

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. --<!-- 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
Regression in
I think it's enough to change to be without .
Code change:
<ins> struct TestClient; impl TestClient { fn get_inner_ref(&self) -> &Vec<usize> { todo!() } } fn main() { let client = TestClient; let inner = client.get_inner_ref(); //~^ HELP consider changing this to be a mutable reference inner.clear(); //~^ ERROR cannot borrow `*inner` as mutable, as it is behind a `&` reference [E0596] } </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. --<!-- 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. --: In case it helps, when using the stable toolchain, the compiler does not panic but instead emits this error: <!-- 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 --
Bisected to . CC searched nightlies: from nightly-2021-10-01 to nightly-2021-11-25 regressed nightly: nightly-2021-11-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: aarch64-apple-darwin Reproduce with: </details label regression-from-stable-to-nightly
I can fix this quickly -- seems like just changing an to a since the can be out of bounds. claim
(only tangentially related) I also noticed a regression in error spans between stable and beta... stable: beta:
That was an intentional change, meant to highlight the fact that the attempted mutable borrow is occurring because of the method call. However, it seems to be confusing for a lot of people, so I'll look into improving it.
Ah thanks for letting me know. Maybe we can split the span up into the receiver and the method, and add a note on the latter like "due to this method which takes &mut self". Not sure if that much info bubbles down into borrowck. I'd be interested in making that change if you've got a lot on your plate and it's (relatively) easy to do.
See for discussion about this exact idea. It'd be nice, but likely hard to implement.
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Code change:
<ins> // Copyright 2016 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. </ins>

Related discussion:
text: Rustdoc defaults to only documented things that are public, i.e. things that the user of a library would care about. This is a good default, but rustdoc can also be useful to people working on large crates by documenting these crates themselves. In that case, it’s preferable to also include private types, fields, functions, and methods. was about this use case, and was closed with this solution: We just tried this on . It’s better than before, but has the unexpected side effect that every item (including non- and the implicit prelude) and every (including the implicit ) is documented under “Reexports”. It can get pretty noisy: ! They’re technically part of the crate, but don’t provide useful information. Could rustdoc split up the pass into one that strips private and , and one for everything else?
Code change:
<ins> // revisions:rpass1 rpass2 struct A; #[cfg(rpass2)] impl From<A> for () { fn from(_: A) {} } fn main() {} </ins>

Related discussion:
text: It have something to do with incremental build :( seems to point to random function sometimes even in file that was not edited for weeks. Issue started today. Deleting folder help for few compilations. I do not use latest compiler because some problems with crate upgrades and incompatibilities with async/await! so the issue is not caused by the compiler version, because I use same version for a while, but it is triggered by something in my code. Is there anything I can look for in my code that could cause these issues?
Remember what you've done between cleaning and ICEing. (maybe auto git commit every save or similar ^^). In my case it was just renaming a variable from to which causes an ICE.
when I think backward it first appeared when I add crate slotmap, and with that crate I was able to reproduce it even with 2 lines edit to their simplest example, so at that point I think it is caused by the crate and removed it and it was fine for a while, I chose to use CHashMap that solve some problems for me. I can not say after which change it reappear.
I want to know if I could use as key because I already have unique so I try to implement trait for struct containing only get error, so I tried to replace their key and still get the error, and when I commented out it compile, I tried few other combinations, but compiler panicked a lot, so I decided it is not the crate I want and removed it prom my project.
triage: I'm going to mark this as P-high, but it might be more of a "medium" bug. It's a bit hard to say. I think there are few bits of info that would be useful: First and foremost, a more concrete recipe for reproducing the problem, ideally with a standalone example Second, some idea if this is a regression -- did the problem only start recently?