jiebi/CodeConvo huggingface dataset:
Change:
if let Directive::Ignore(false) = skip_tab { tidy_error!(bad, "{}: ignoring tab characters unnecessarily", file.display()); } <del> // FIXME: Temporarily disabled to simplify landing the ignore-rules for the line // length check (https://github.com/rust-lang/rust/issues/77548): //if let Directive::Ignore(false) = skip_line_length { //    tidy_error!(bad, "{}: ignoring line length unnecessarily", file.display()); //} </del> <ins> if let Directive::Ignore(false) = skip_line_length { tidy_error!(bad, "{}: ignoring line length unnecessarily", file.display()); } </ins> if let Directive::Ignore(false) = skip_file_length { tidy_error!(bad, "{}: ignoring file length unnecessarily", file.display()); }

Discussion:
UI tests regularly have long lines due to the annotations. So it is not very helpful for tidy to complain about overly long lines... every single time that happened, I ended up adding (the amount of time it took me to figure out the exact way to do this went down from 3-5min the first time to <20s by now). To make test maintenance even more annoying, when an error message changes to become shorter, tidy will complain about the ignore flag being unnecessary! And each time the flag is or removed, you need to re-bless the tests as line numbers change. This chore doesn't really seem worth it. We don't the test suite either. Can we just disable the line length checker in the test suite please? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We can add a check similar to to disable just the line length limits for UI tests.
Hey, first time contributor here happy to give this a shot! I think I get what's going on here, but do you have any pointers for where I should be looking exactly?
I would add a "intests" check similar to the the underrustfmt one here , and then add it to the conditional here to not run that lint in tests.
Is the plan suggested in still good?
yeah I'd say it is. actually did most of the work (adjusting tidy); someone just has to do the multi-stage landing process: in a first PR, land the tidy change with disabled "ignoring length unnecessarily" (and probably adjust no existing tests, to keep conflicts down) then in a second PR, remove the unnecessary ignore-line-length comments (probably still keeping "ignoring length unnecessarily" disabled as more tests will trickle in that still have the ignore-line-length flag) after 2 weeks or so, re-enable the "ignoring length unnecessarily" test Step 3 is assuming that we truly want to keep that check. I personally think it is somewhat silly, but I assume it was because people want it, so maybe we should keep it.
claim
thank you so much for pushing this through. :-)
Thanks to your quick advice and great preparatory work this was in fact pretty easy. I'm very impressed by the tooling and automation surrounding the contribution process! :muscle:
Change:
| = help: ensure that all possible cases are being handled, possibly by adding wildcards or more match arms = note: the matched value is of type `isize` <ins> = note: `isize` does not have a fixed maximum value, so a wildcard `_` is necessary to match exhaustively = help: add `#![feature(precise_pointer_size_matching)]` to the crate attributes to enable precise `isize` matching </ins> error: aborting due to 2 previous errors

Discussion:
Gives:
Fairly sure this is intentional for
From the pull I've seen a part that I didn't see/remember: An unstable feature precisepointersizematching will be to permit matching exactly on pointer-size integer types. So you're right, this isn't a new bug, it's a known unfinished part. I hope to see that precisepointersizematching implemented.
It already exists.
I see, then what do I have to hope to see? :-)
I'm not sure the feature is ever going to be stabilised, because there are concerns that this isn't a desirable feature. But hopefully the diagnostics will at least be improved in
Do you have a link to such concerns? (Or are you willing to summarize them?) (I value your work on the compiler a lot varkor :-) )
I think the relevant concerns arose in the (from this comment up). The overview is that we ought not to make assumptions about pointer sizes on the target platform, because they're not guaranteed to be fixed, so this could cause compatibility issues.
Change:
writeback::resolve_type_vars_in_expr(fcx, e); } <ins> /// Checks whether a type can be represented in memory. In particular, it /// identifies types that contain themselves without indirection through a /// pointer, which would mean their size is unbounded. This is different from /// the question of whether a type can be instantiated. See the definition of /// `check_instantiable`. pub fn check_representable(tcx: ty::ctxt, sp: Span, item_id: ast::NodeId, designation: &str) { let rty = ty::node_id_to_type(tcx, item_id); // Check that it is possible to represent this type. This call identifies // (1) types that contain themselves and (2) types that contain a different // recursive type. It is only necessary to throw an error on those that // contain themselves. For case 2, there must be an inner type that will be // caught by case 1. match ty::is_type_representable(tcx, rty) { ty::SelfRecursive => { tcx.sess.span_err( sp, format!("illegal recursive {} type;  wrap the inner value in a box to make it representable", designation)); } ty::Representable | ty::ContainsRecursive => (), } } </ins> /// Checks whether a type can be created without an instance of itself. /// This is similar but different from the question of whether a type /// can be represented.  For example, the following type:

Discussion:
The following program causes a stack overflow: There is a check that enums do not recurse in this way, but no such check for structs. (Note, though, that there is a check that structrs are instantiable, which is slightly different)
Huh, so that's why std::list has pointer indirections in it.
This is still an issue, nominating for production ready
accepted for production-ready milestone
So uh, this... doesn't exactly reproduce. It compiles and runs fine, no overflow or anything afaict. It should be rejected by the compiler, I think.
you have to reference the type, just like , which I triaged today. Actually I think they are the same bug.
This applies to non-infinite-sized types that contain themselves unboxed like the following too:
Accepted for 1.0, P-high.

Here is a test case: I think the right approach is to replace with something like . then we have to keeep a stack of def-ids and when we enter a new nominal type check that we do not already have it on the stack. i started this then realized it was a big distraction from what I'm trying to do, so filing a bug instead. Marking as A-typesystem as this check is performed in
Just to make this concrete: both of the cases that Niko describes yield ICE's. The first (the and items) yields an ICE with no useful error information. The second ( and ) yields an error describing the illegal recursive enum type (followed by an ICE :).
I don't believe this is backwards incompatible, renominating.
accepted for production-ready milestone
appears to be properly classified
Accepting for P-high.
Tagging as mentorship bug, with as mentor
This code triggers the same infinite recursion in typestructurallycontains:
I have a fix for this written, in case anyone is wondering whether to start working on it. I'll submit a pull request soon.
Change:
<ins> warning: the feature `const_generics` is incomplete and may cause the compiler to crash --> $DIR/issue-70125-2.rs:3:12 | LL | #![feature(const_generics)] |            ^^^^^^^^^^^^^^ | = note: `#[warn(incomplete_features)]` on by default </ins>

Discussion:
: <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Got same error with: It seems unrelated to the type of the const
claim
Reduced: Looks like a normalization failure to me, but that shouldn't happen for .
So I found the bug, is just outright missing : <hr/But also, it's worrying that an equivalent to this is missing for consts (even if it's not relevant here):
For the record, what I described above () isn't fixed, just worked around. EDIT: opened .
Change:
sign_extend, truncate, AllocId, FrameInfo, GlobalId, InterpResult, Pointer, Scalar, }; use rustc_middle::ty::layout::{self, TyAndLayout}; <del> use rustc_middle::ty::query::TyCtxtAt; use rustc_middle::ty::subst::SubstsRef; use rustc_middle::ty::{self, Ty, TyCtxt, TypeFoldable}; </del> <ins> use rustc_middle::ty::{ self, fold::BottomUpFolder, query::TyCtxtAt, subst::SubstsRef, Ty, TyCtxt, TypeFoldable, }; </ins> use rustc_span::source_map::DUMMY_SP; <del> use rustc_target::abi::{Abi, Align, HasDataLayout, LayoutOf, Size, TargetDataLayout}; </del> <ins> use rustc_target::abi::{Align, HasDataLayout, LayoutOf, Size, TargetDataLayout}; </ins> use super::{ Immediate, MPlaceTy, Machine, MemPlace, MemPlaceMeta, Memory, OpTy, Operand, Place, PlaceTy,

Discussion:
The following ICEs (example by shows This means that is wrong. It might be possible to also trigger this without nightly features through const_prop.
Baring a way to do the proper structural subtyping check, the only solution I see is to go back to comparing layouts in all cases (as a fallback after types mismatch) -- but does not like this, as far as I recall. Any other proposals?
Change:
use crate::ty::{GenericArg, GenericArgsRef}; use rustc_hir::def_id::{CrateNum, DefId, LocalDefId, LocalModDefId, ModDefId, LOCAL_CRATE}; use rustc_hir::hir_id::{HirId, OwnerId}; <ins> use rustc_query_system::query::DefIdCacheSelector; </ins> use rustc_query_system::query::{DefaultCacheSelector, SingleCacheSelector, VecCacheSelector}; use rustc_span::symbol::{Ident, Symbol}; use rustc_span::{Span, DUMMY_SP};

Discussion:
Per-crate cache maps keyed on may be more efficient and/or allow us to use for queries keyed on instead of . We can use specialization (e.g. for splitting into and ), I think. cc
Sounds like a good idea if the lookup array ends up being densely populated enough. In general, we should provide a way to implement customized in-memory caching for specific queries.
Change:
<ins> // compile-flags -Wrust-2021-incompatible-closure-captures fn main() {} pub(crate) struct Numberer {} impl Numberer { pub(crate) async fn new( //~^ ERROR `async fn` is not permitted in Rust 2015 interval: Duration, //~^ ERROR cannot find type `Duration` in this scope ) -> Numberer { Numberer {} } } </ins>

Discussion:
Works even with calling just - no need for a project, and does not need as a dependency in . Bug exists on 1.59, 1.60, beta and nightly. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Do you have a codebase that can be shared instead? Unfortunately, it's kinda difficult to investigate this without seeing what triggered the ICE.
might be a duplicate of
I tried my hands at minimizing this, and it turned out way easier than I thought. Updated the original comment with reproduction code.
I subscribed to this thread for curiosity about ICEs on . Here's a smaller crashing program using
Managed to minimize it more:
you might be right, especially after I narrowed down the reproduction code.

<!-- 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 reduced 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
another example: `
Change:
/// error E0416: identifier is bound more than once in the same pattern IdentifierBoundMoreThanOnceInSamePattern(&'a str), /// error E0417: static variables cannot be referenced in a pattern <del> StaticVariableReference, </del> <ins> StaticVariableReference(DefId, Option<Name>), </ins> /// error E0418: is not an enum variant, struct or const NotAnEnumVariantStructOrConst(&'a str), /// error E0419: unresolved enum variant, struct or const

Discussion:
Rustc version: rustc 1.0.0-nightly ( 2015-03-22) (built 2015-03-23)
Hmm, I am not sure if this is a bug or not. I can see it both ways.
As I understand, this error is related to the situation like this
Change:
|| !matches!(&indirect_offsets[..], [Size::ZERO] | [])); if should_create_individual_allocas { <ins> let DebugInfoOffset { direct_offset: _, indirect_offsets: _, result: place } = calculate_debuginfo_offset(bx, local, &var, base); </ins> // Create a variable which will be a pointer to the actual value let ptr_ty = bx.tcx().mk_ty(ty::RawPtr(ty::TypeAndMut { mutbl: mir::Mutability::Mut,

Discussion:
When generating a variable debuginfo, rustc emits an expression describing the address of a source variable. Since , rustc also evaluates this expression. The expression can contain indirections, and it is not always valid to evaluate it. Consider a source variable that is described indirectly in terms of a base local. The source variable will be introduced at the beginning of a function, but at this point the base local might be uninitialized. For example: Note that has and metadata but loaded value is uninitialized. (This leads to end-to-end miscompilation with -Cdebuginfo=2). cc
A variant that demonstrates complete end-to-end miscompilation can be found in
Even without the metadata, this load could violate constraints. So just removing the metadata is not a proper fix. EDIT: Or does this always load from an that doesn't have any other pointers to it yet? Then it should be fine in terms of aliasing.
Change:
all_sync_send!(Vec::<usize>::new(), into_iter); is_sync_send!(Vec::<usize>::new(), drain(..)); <ins> is_sync_send!(String::new(), drain(..)); </ins> }

Discussion:
cc
The rfc says It also includes an example which depends on usize: However RangeArgument only implements the first four. Furthermore as things stand it does not appear possible to accept RangeArgument<usizeand usize simultaneously, because dispatch doesn't consider the trait bound and reports that conflicting implementations exist.
Yes, was explicit about these issues. I forsee a new RFC to finish off drain and maybe the RangeArgument trait.
I believe this has
Change:
<ins> fn foo(c: &[u32], n: u32) -> u32 { match *c { [h, ..] if h > n => 0, [h, ..] if h == n => 1, [h, ref ts..] => foo(c, n - h) + foo(ts, n), //~^ ERROR expected one of `,`, `@`, `]`, or `|`, found `..` [] => 0, } } </ins>

Discussion:
Gives: I think a better error message should suggest the usage of . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This gets us to:
Format and help message revised to:
Merged. Thanks for the report!
Change:
CodeBlockKind::Fenced(ref lang) => { LangString::parse_without_check(&lang, self.check_error_codes, false) } <del> CodeBlockKind::Indented => LangString::all_false(), </del> <ins> CodeBlockKind::Indented => Default::default(), </ins> }; if !parse_result.rust { return Some(Event::Start(Tag::CodeBlock(kind)));

Discussion:
is not actually allfalse - will return . It would be nice to rename it to at some point (and maybe add while we're at it). cc Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim I'll either get to it before next week is over or when is merged, whichever comes first
Change:
InferCtxt, LateBoundRegion, HigherRankedType, <ins> RegionVariableOrigin, </ins> SubregionOrigin, SkolemizationMap}; use super::combine::CombineFields;

Discussion:
This code: Produces this internal compiler error: Interestingly, changing to or causes the code compile fine (modulo unused variable warnings). : Backtrace:
This is a regression in 1.17.0-beta. Earlier versions give:
Duplicate of .

Rustc crashes on code that uses and crates. I tried this code: (I was unable to reproduce this without discord crate so far) I expected to see this happen: cargo build works Instead, this happened: : rustc 1.17.0-nightly ( 2017-02-20) binary: rustc commit-hash: commit-date: 2017-02-20 host: x86_64-apple-darwin release: 1.17.0-nightly LLVM version: 3.9
For the reference, generated file: Replacing with the code above produces the exact same ICE
This is a regression in 1.17.0-beta. Earlier versions give: The stacktrace looks a lot like and which have much simpler repros.
Change:
<del> //@ known-bug: rust-lang/rust#125881 #![crate_type = "lib"] #![feature(transmutability)] #![feature(unboxed_closures,effects)] const fn test() -> impl std::mem::TransmuteFrom() { || {} } </del>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'not implemented: NormalizationFailure(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. }), Type(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. })))'', 'thread 'rustc' panicked at 'not implemented: NormalizationFailure(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. }), Type(Alias(Projection, AliasTy { args: [T/], defid: DefId(0:12 ~ a[cc78]::Aaa::Y), .. })))'' 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: [checkwellformed] checking that is well-formed [checkmodtypewf] checking that types are well-formed in top-level module --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regression in nightly-2024-08-22 seems to bisect to
Slightly more reduction:
(Note that this reduction should drop the feature gate, as this ICEs without the feature gate)
claim
Change:
trait Baz<'f> { } <ins> // `Derive`d impls shouldn't trigger a warning, either (Issue #53738). #[derive(Debug)] struct Quux<'a> { priors: &'a u32, } </ins> fn main() { }

Discussion:
When compiling this warning is generated: I think, in the derive does not consider this lint.
I tried to in the compiler but hit this bug, which makes it a non-starter. I'd almost change built-in deriving to not declare the lifetimes explicitly but I suspect that wouldn't work when using nested within a block where the shadowing from explicitness would be useful. (That's assuming built-in deriving actually uses these lifetimes in bounds, otherwise it could just use ) cc
cc
I don't think this seems high priority. I'll leave it nominated but I'm prioritizing it as P-medium.
The problem is that the above code expands to something similar to which correctly warns for the in the . But since in the original code the impl is derived and reusesthe from the struct declaration, the lint appears to trigger on the struct declaration. We may either just want to not trigger in derive expansions or explicitly allow this lint in derives expansions.
advertised at T-compiler meeting. removing nomination tag.
I'm going to ping in the hopes that they have a bit of time to look into this. My sense is that we ought to make a plan to finish up the Rust 2018 idiom lints -- but at the same time it's hard to justify a P-high label just now.
I tried an approach where I would look at the lifetime span to see if it came from a compiler desugaring, but the derived code doesn't keep any information about their context. A different approach will be needed in the parse step to make sure the debug subparser produced spans are appropriately marked. I won't have time to dig deeper, but wanted to share what I found.
AFAIK there's a perma-unstable attribute that is placed on derived s which some error reporting code might be checking. I should've given more context - it'd be good to fix this because it would unblock something like , but likely removing a far larger number of lifetimes, which may simplify e.g. the removal. But if we can't really soon, we can defer indefinitely, I think.
?
This seems to have regressed.
Change:
match binding { Ok(binding) => { // Consistency checks, analogous to `finalize_macro_resolutions`. <del> let initial_res = source_bindings[ns].get().map(|initial_binding| { </del> <ins> let initial_binding = source_bindings[ns].get().map(|initial_binding| { </ins> all_ns_err = false; if let Some(target_binding) = target_bindings[ns].get() { if target.name == kw::Underscore

Discussion:
thread 'rustc' panicked at ': inconsistent resolution for an import', <details<summaryBacktrace</summary</detailsRegression in nightly-2018-12-30 <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Same error message as , but this one is self-contained and might be a separate bug.
claim
how about make this to an error with diagonostic? Seems we don't have a chance to insert , because the is before the later . If we change code to this: It will be:
Could we register an exactly in the place we ICE?
Yes, this is also a solution, and then we can report error in the same function .
Change:
use common::{Codegen, DebugInfoLldb, DebugInfoGdb, Rustdoc, CodegenUnits}; use common::{Incremental, RunMake, Ui, MirOpt}; use errors::{self, ErrorKind, Error}; <ins> use filetime::FileTime; </ins> use json; use header::TestProps; use header;

Discussion:
Right now, if you work on a mir-opt test and iteratively change it without cleaning in between runs, your build directory can end up with content like this: Note the wide variety of timestamps. As the node id's changed in response to source file modifications, some of the output stops getting overwritten and just stays in place. This, combined with the mir-opt architecture where one embeds the name of the specific file that one wants to compare against, has a bad failure case during iterative development: if you are not paying attention and leave the header as e.g. , you'll keep comparing your expected output against the same (stale) file, so you'll either get false negatives (the test passes because the embedded expected output is just as stale as the file you end up comparing against), or as you revise your concrete test input, you'll get false positives (the test fails because the now correct embedded expected output is still being compared against a stale file). The user error here is of course that the needs to be kept in sync with the actual node number to which the mir dump sends its output. But it would be much better if did a sanity check on the time stamps: if the dumped mir output is older than the original source file, then chances are something has gone wrong, and compile test could either error in response, or at least issue a warning to the user.
(I have a patch for this; will post shortly)