jiebi/CodeConvo huggingface dataset:
Change:
<ins> // issue: 120878 fn main() { struct StructA<A, B = A> { _marker: std::marker::PhantomData<fn() -> (A, B)>, } struct StructB { a: StructA<isize, [u8]>, //~^ ERROR: the size for values of type `[u8]` cannot be known at compilation time [E0277] } trait Trait { type P<X>; } impl Trait for () { type P<X> = [u8]; //~^ ERROR: the size for values of type `[u8]` cannot be known at compilation time [E0277] } } </ins>

Discussion:
No response No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Another variant of this error I came up with using stable Edit Just tested on stable and . Both produced the same output.
claim
This is only tangentially related but just to give more context to anyone stumbling upon this issue: The diagnostic highlighting the entire path instead of only the type argument is tracked in .
Change:
use rustc_middle::middle::stability::EvalResult; use rustc_middle::span_bug; use rustc_middle::ty::print::with_no_trimmed_paths; <del> use rustc_middle::ty::{ self, suggest_constraining_type_params, Article, Binder, IsSuggestable, Ty, TypeVisitableExt, Upcast, }; </del> <ins> use rustc_middle::ty::{self, suggest_constraining_type_params, Article, Binder}; use rustc_middle::ty::{IsSuggestable, Ty, TyCtxt, TypeVisitableExt, Upcast}; </ins> use rustc_session::errors::ExprParenthesesNeeded; use rustc_span::source_map::Spanned; use rustc_span::symbol::{sym, Ident};

Discussion:
when using i even got this suggestion recommending i return DefKind from the GlobalCtxt::enter closure, which isn't even remotely the right type. it also seems to only show up when using macros? all around quite strange. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Change:
} impl<'a, 'tcx> LateLintPass<'a, 'tcx> for UnusedMut { <del> fn check_expr(&mut self, cx: &LateContext, e: &hir::Expr) { if let hir::ExprMatch(_, ref arms, _) = e.node { for a in arms { self.check_unused_mut_pat(cx, &a.pats) } } </del> <ins> fn check_arm(&mut self, cx: &LateContext, a: &hir::Arm) { self.check_unused_mut_pat(cx, &a.pats) </ins> } <del> fn check_stmt(&mut self, cx: &LateContext, s: &hir::Stmt) { if let hir::StmtDecl(ref d, _) = s.node { if let hir::DeclLocal(ref l) = d.node { self.check_unused_mut_pat(cx, slice::ref_slice(&l.pat)); } } </del> <ins> fn check_local(&mut self, cx: &LateContext, l: &hir::Local) { self.check_unused_mut_pat(cx, slice::ref_slice(&l.pat)); </ins> } fn check_fn(&mut self,

Discussion:
seems to be ignored For example: I expected to see no warning about the mut flag of a Instead, this happened: This currently happens on all 3 major branches: stable, beta, nightly: Backtrace: does not give more information.
Note that increasing the scope of the avoids the warning as expected: Unclear whether applying the to the should be sufficient.
I'm guessing that the lint passes were just not updated when attributes were allowed to be attached to statements.
The lint pass runs on functions, not on single statements, since you can't decide whether the should be linted just by looking at the statement. This is a failure of the current lint system and hard to address.
cc
The lint pass runs on functions, not on single statements, since you can't decide whether the should be linted just by looking at the statement. This is a failure of the current lint system and hard to address. is also ignored when statement is located inside of a macro, regardless of whether is located above the statement, macro, or function in which macro is called: ,L235 It would be nice if it did work for single statements inside of a macro. Main channels are still affected: stable: rustc 1.20.0 ( 2017-08-27) beta: rustc 1.21.0-beta.3 ( 2017-09-15) nightly: rustc 1.22.0-nightly ( 2017-09-14)
Change:
//~^ ERROR mismatched types foo::<i32>(x_u32.try_into().unwrap()); //~^ ERROR mismatched types <del> foo::<i32>(x_u16.try_into().unwrap()); </del> <ins> foo::<i32>(x_u16.into()); </ins> //~^ ERROR mismatched types <del> foo::<i32>(x_u8.try_into().unwrap()); </del> <ins> foo::<i32>(x_u8.into()); </ins> //~^ ERROR mismatched types foo::<i32>(x_isize.try_into().unwrap()); //~^ ERROR mismatched types

Discussion:
() Errors: I would’ve expected something like: Edit: What actually should happen is the same as currently already with , i.e. it would look like modify labels: A-diagnostics, T-compiler, D-papercut, C-enhancement, E-easy <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Okay, lots of cases that already work got me confused into thinking this was fixed in nightly for a moment. What currently already works is the hint about converting where < where < What currently suggest even though works where < where ≤16 where ≤16
I reported a similar issue not long ago. Maybe it would be more robust and also more general to rewrite this suggestion code to actually look for the impl in question instead of having just a hard-coded list?
claim
I've created a PR augmenting the existing code to change the suggestions for the cases listed. However, I would like to explore the approach suggested(perhaps as part of a separate PR?). Any advice on how I could get the code to look for the impl so it can make the appropriate suggestion? Is the crate the right place to be looking at for this?
Yeah. I believe you'll need to create an and and then call , but there might be other/better ways to do this. You might want to ask for advice on Zulip.
Change:
// Functions without bodies cannot have patterns. if let FnKind::Fn(ctxt, _, sig, _, None) = fk { <del> Self::check_decl_no_pat(&sig.decl, |span, mut_ident| { </del> <ins> Self::check_decl_no_pat(&sig.decl, |span, ident, mut_ident| { </ins> let (code, msg, label) = match ctxt { FnCtxt::Foreign => ( error_code!(E0130),

Discussion:
Taken from We should suggest to use an identifier. When possible take that identifier from the pattern, otherwise should work just as well. CC
I'll try it!
Change:
<ins> error[E0170]: pattern binding `C` is named the same as one of the variants of the type `Foo` --> $DIR/issue-88730.rs:12:8 | LL | fn foo(C: Foo) {} |        ^ | note: the lint level is defined here --> $DIR/issue-88730.rs:2:9 | LL | #![deny(bindings_with_variant_name)] |         ^^^^^^^^^^^^^^^^^^^^^^^^^^ error[E0170]: pattern binding `C` is named the same as one of the variants of the type `Foo` --> $DIR/issue-88730.rs:15:9 | LL |     let C = Foo::D; |         ^ error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0170`. </ins>

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. --Given the following code: The current output is: Ideally the lint should not trigger on such a pattern, it does not really make sense and the suggestion is wrong altogether,
label: +D-confusing +D-incorrect
Note that the suggestion isn't wrong in this particular case, because can actually match any Foo. It's wrong only when has 2+ variants.
Right, the real world case of this was with the ascii crate with the AsciiChar enum, this is just a tiny test case
Change:
<ins> // check-pass #![feature(const_generics)] //~^ WARN the feature `const_generics` is incomplete and may cause the compiler to crash pub trait Trait<const N: usize>: From<<Self as Trait<N>>::Item> { type Item; } fn main() {} </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. --I was writing some generic code over vectors using the under-construction feature of const generics, and had a circular chain of super-traits that required me to cast the Self type to the trait as can be seen in the supertrait requirement. I believe that is causing the MIR error. I think this may be related to but it is subtly different so I'm putting the issue up regardless. <!-- 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. --: I updated my rust version on nightly right before I ran this so hopefully it is up to date: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimized: claim
Looks like maybe constants in trait paths don't get their type correctly? cc
Initially I thought this was about bounds but no, this also fails: ()
I believe this code is responsible: And the problem is that this doesn't handle associated types which need the same treatment:
Alternatively, instead of using to get the , maybe we could use the olution from the segment we found the const parameter in? I believe nowadays we have per-segment resolutions, which would avoid breaking GATs in the future. Actually, I expect is also broken, let's try it... Yupp: () EDIT: took a second look and that is in a , which has to be resolved by the body of , which means it's as bad as the method call form (which I just ). Maybe we should disallow passing explicit generic args to methods for now? Since I have no idea how one would figure out the expected type.
If you look at this later btw, my comment above () still isn't addressed, but I haven't made an issue yet about it.
Change:
hir::MatchSource::Normal => { let mut err = struct_span_err!(cx.tcx.sess, pat.span, E0001, "unreachable pattern"); <ins> err.span_label(pat.span, &format!("this is an unreachable pattern")); </ins> // if we had a catchall pattern, hint at that for row in &seen.0 { if pat_is_catchall(&cx.tcx.def_map.borrow(), row[0].0) {

Discussion:
From: src/test/compile- We need to add a span_label to update E0001 from: To:
Taking it
Change:
} debug_assert!( <del> [token::DotDot, token::DotDotDot, token::DotDotEq].contains(&self.token.kind), </del> <ins> self.token.is_range_separator(), </ins> "parse_prefix_range_expr: token {:?} is not DotDot/DotDotEq", self.token );

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. --Given the following code: <!-- Please provide a link to --The current output is: is a valid expression (a  literal), so this error is misleading. It should at a minimum have a suggestion to replace with the valid version , and probably should just work. It also imho ideally shouldn't be a hard parser error blocking semantic passes; the parse of is fairly unambiguously intended, even if we decide we should still require the parenthesis. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'm interested! Where should I look first? (I have no experience in rustc, some general experience in compilers tho)
The is a good place to start. If you have some compiler development experience already, that should get you going quickly enough. One specifically relevant section is is likely to be where you'll need to change. Also, ; you can to assign yourself to the issue to track that you're working on it.
For extra context, is accepted in expression position at least for both , , and obviously , so I have absolutely no idea what makes different that it causes a parser error in this case.
claim
Change:
if let Ok(check) = cast::CastCheck::new( &fn_ctxt, e, from_ty, to_ty, // We won't show any error to the user, so we don't care what the span is here. <del> DUMMY_SP, DUMMY_SP, </del> <ins> DUMMY_SP, DUMMY_SP, hir::Constness::NotConst, </ins> ) { let res = check.do_check(&fn_ctxt);

Discussion:
Compiles in stable rust (1.64) as well as in beta. But in nightly, we get this compilation error: playground link: 64, and beta current nightly
searched nightlies: from nightly-2022-08-01 to nightly-2022-10-24 regressed nightly: nightly-2022-09-23 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Seems like closures pick the constness of their parent when they should always be notconst
Change:
use crate::os::windows::prelude::*; use crate::borrow::Cow; <del> use crate::ffi::OsString; </del> <ins> use crate::ffi::{c_void, OsString}; </ins> use crate::fmt; use crate::io::{self, BorrowedCursor, Error, IoSlice, IoSliceMut, SeekFrom}; use crate::mem::{self, MaybeUninit};

Discussion:
Reported on discord, using will fail on Windows if the file is hidden. This also affects methods like or that open the file the same way. The reason for this is that we use , which has : So to make it work the caller needs to match the requested attributes to the existing attributes at the time of opening. It was suggested we could instead use and then manually truncate the file using to zero.
Manually truncating would require also clearing the alternate data streams too, right? And it would presumably stop erroring if another process still has the file open and instead corrupt the file fron the view of the other process.
No? The proposed solution would work the same was as in the case where the file already exists. Which we use for .
Right, got confused with .
Change:
sp: Span, tts: &[tokenstream::TokenTree]) -> Box<base::MacResult + 'static> { <ins> let sp = sp.with_ctxt(sp.ctxt().apply_mark(cx.current_expansion.mark)); </ins> let mut p = cx.new_parser_from_tts(tts); let cfg = panictry!(p.parse_meta_item());

Discussion:
If any linting or suggestion is done in this case, it should suggest cc this has been in rustc forever, but clippy is only lately going crazy on it. Could this have come from your PR, too?
Hmm, shouldn't have been affected, but I'll investigate.
this is messing up clippy pretty bad. Any idea where to start looking?
So I tried to figure out what's going on, but I got lost in the code. As far as I can see it should be setting the expansion info. But it appears the passed to doesn't contain the expansion info. So maybe we need to generate a new span here with the from ?
The span passed to is the call site span, so it shouldn't contain the expansion info. The issue here is that is using the call site span directly in the expansion ( is call site span). To fix this, the macro should add expansion info to the call site span like does . Adding that line in should fix this issue. Are there other built-in macros that also have this problem in practice or is it just ?
I'd assume others have it too, but I'll check. So the passed call site span should only be used directly for error reporting, but never for creating ast items?
Right, unless you want an AST item with the raw (unexpanded) call site span -- I don't think we ever want that.
Change:
<ins> Hello(0) Hello(0) Hello(1) Hello(1) Hello(2) Hello(3) Hello(3) Hello(4) Hello(4) Hello(5) </ins>

Discussion:
Something is still wrong w/ async call shims. I think I'm not doing the transform correctly or something. Putting this up so I don't forget about it, but I'll fix it.
ohhhhh lol it's drop glue. Huh.
Oh hell yes this is actually totally wrong wtf:
Change:
<del> // check-pass #![feature(const_trait_impl, effects)] #[const_trait] trait Foo { fn foo(&self) {} } struct Bar<T>(T); impl<T> Bar<T> { const fn foo(&self) where T: ~const Foo { self.0.foo() } } fn main() {} </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: no host param id for call in const yet no errors reported', 'error: internal compiler error: no host param id for call in const yet no errors reported' 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: --
Regression in nightly-2023-08-09
Change:
} } <ins> ast::ItemStruct(..) => { if attr::contains_name(i.attrs, "simd") { self.gate_feature("simd", i.span, "SIMD types are experimental and possibly buggy"); } } </ins> _ => {} }

Discussion:
Our support isn't very complete at all, and details of the interface may change.
Nominating.
Accepted for P-backcompat-lang.
I'm working on this
Change:
use rustc_trait_selection::traits::ObligationCtxt; use rustc_trait_selection::traits::{self, ObligationCauseCode}; <ins> use smallvec::SmallVec; </ins> impl<'a, 'tcx> FnCtxt<'a, 'tcx> { pub fn check_expr_has_type_or_error( &self,

Discussion:
<!-- [31mICE[0m: Rustc '-Zincremental-verify-ich=yes -Cincremental=<dir-Cdebuginfo=2' 'thread 'rustc' panicked at 'forcing query with already existing '', 'thread 'rustc' panicked at 'forcing query with already existing '' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion 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: note: compiler flags: -Z incremental-verify-ich=yes -C incremental=[REDACTED] -C debuginfo=2 [findfield] find the index of maybe nested field in [typeck] type-checking [analysis] running analysis passes on this crate --
This bisects to :thinking:
WG-prioritization assigning priority (). cc: + for label -I-prioritize +P-medium
I'm going to fix it in (still WIP), where the query will be removed.
Testing out on this issue:
I seems like does not have proper or impls, possibly due to the differing . Are you familiar with that part of spans?
Change:
<del> Subproject commit 2751bdcef125468ea2ee006c11992cd1405aebe5 </del> <ins> Subproject commit 34fca48ed284525b2f124bf93c51af36d6685492 </ins>

Discussion:
Results in a crash (after a perfectly reasonable error message): This was tested with rustc 0.1. Building from HEAD on nyus now to try to get a more helpful backtrace and to verify that it hasn't since been fixed.
Here's a more helpful backtrace. Repros at .
Looks exactly like to me.

On the pull request for (), had a good suggestion for what I think would make a good additional function: "a version of frombytes which doesn't fail on invalid input but rather offers some sort of error recovery options. Like maybe it can return the partly converted string with an index to the invalid position. Or perhaps, a callback function to handle the error, etc." At a glance the easy way to do this would be with a callback to, e.g., drop, replace, or coerce offending sequences into UTF-8 or else return a ... But is this a recipe for complex callbacks? Perhaps providing sensible callback functions like , , , and so on would make this simple enough to use. Maybe those should just be simple functions for whole byte vector conversion, anyways. What do you think?
I don't have a strong opinion about it, but I guess I would prefer to wait until somebody actually needs something like this.
Not RFC-level proposal. Just a library wishlist item. Might accept a patch; but it seems a bit overwrought. Anyone need such a thing yet?
I think this is subsumed in ; we might well adopt a dynamic-handler mechanism while working through that bug. This would be a special case.
Change:
<ins> error[E0512]: cannot transmute between types of different sizes, or dependently-sized types --> $DIR/issue-79494.rs:5:29 | LL | const ZST: &[u8] = unsafe { std::mem::transmute(1usize) }; |                             ^^^^^^^^^^^^^^^^^^^ | = note: source type: `usize` (64 bits) = note: target type: `&[u8]` (128 bits) error: aborting due to previous error For more information about this error, try `rustc --explain E0512`. </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. --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
label -T-compiler +T-rustdoc
MCVE: I expect this is the same sort of issue as where rustdoc ignores errors that the compiler requires to be emitted. Assigning P-low by the same rationale as
I found a similar duplicate.
Triage: fixed by , marking as .
Change:
lvl: Level) { let error = match sp { Some(COMMAND_LINE_SP) => self.emit_(FileLine(COMMAND_LINE_SP), msg, code, lvl), <ins> Some(DUMMY_SP) | None => print_diagnostic(&mut self.dst, "", lvl, msg, code), </ins> Some(sp) => self.emit_(FullSpan(sp), msg, code, lvl), <del> None => print_diagnostic(&mut self.dst, "", lvl, msg, code), </del> }; if let Err(e) = error {

Discussion:
This code isn't valid Rust: We have an okay, but not great, diagnostic here: It might be nice to add a when the keyword found is that mentions that is not an expression, and so cannot be used in this way.
want to work on this? It's a similar task to the other doc comment one, but much simpler since it's a very specific situation.
I'd be happy to help someone :)
So, the parser already has its ways to differentiate keywords from identifiers. All we have to do is find the right place where that error is thrown, check whether it's a and add a note along with the error. The parser has all sorts of code, and adding a note's also around there somewhere :) Code:
I would like to try this. :)
Awesome! Feel free to ask waffles or me for help (you can find us both on IRC on #rust-internals), or ask questions here. (self-assigning since I can't assign to you -- just to mark it as "being taken")
Change:
// // Local Variables: <del> // mode: C++ </del> <ins> // mode: rust </ins> // fill-column: 78; // indent-tabs-mode: nil // c-basic-offset: 4

Discussion:
This compiles and runs without warnings: I at least expected the unused attribute lint to catch this
They are not ignored, it's just that attributes on item macros apply to the macro expansion rather than the resultant item, e.g this errors as expected as the macro isn't expanded.
Ah, and they're removed when the macro is expanded, which is why the lint doesn't pick them up.
Yeah as noted this is actually working as intended, so closing.
I still feel uneasy about the lint missing these attributes, but I guess that cannot be fixed unless the attribute system is rewritten