jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Copyright 2013 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. // error-pattern:explicit failure fn main() { &fail!() } </ins>

Discussion:
(updated test case for bug) The following test inputs: or, more elaborately: yields the ICE failure: (original bug test case follows)
This may or may not be the same failure as which fails with .
Visited for triage. Was able to reproduce. Nominating for "maturity number 5 - production ready".
accepted for production-ready milestone
just a bug, removing milestone/nomination.
Both the smaller and the bigger versions still ICE as of
Change:
<ins> fn main() { [1; <Multiply<Five, Five>>::VAL]; //~ ERROR evaluation of constant value failed } trait TypeVal<T> { const VAL: T; //~ ERROR any use of this value will cause an error } struct Five; struct Multiply<N, M> { _n: PhantomData, //~ ERROR cannot find type `PhantomData` in this scope } impl<N, M> TypeVal<usize> for Multiply<N, M> where N: TypeVal<VAL> {} //~^ ERROR cannot find type `VAL` in this scope //~| ERROR not all trait items implemented, missing: `VAL` </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by
Regression occurred in Rust 1.36.0 per testing in Godbolt.
Regression in nightly-2019-04-24 Range: ... found 9 bors merge commits in the specified range commit[0] 2019-04-22UTC: Auto merge of - varkor:tidy-leading-newline, r=alexcrichton commit[1] 2019-04-22UTC: Auto merge of - estebank:continue-eval, r=oli-obk commit[2] 2019-04-23UTC: Auto merge of - euclio:pulldown-cmark, r=GuillaumeGomez commit[3] 2019-04-23UTC: Auto merge of - davazp:fix-sync-all-macos, r=KodrAus commit[4] 2019-04-23UTC: Auto merge of - varkor:tidy-double-trailing-newline, r=kennytm commit[5] 2019-04-23UTC: Auto merge of - estebank:continue-evaluating, r=oli-obk commit[6] 2019-04-23UTC: Auto merge of - stepnivlk:visit_subpats-removal, r=varkor commit[7] 2019-04-23UTC: Auto merge of - davidtwco:issue-, r=oli-obk commit[8] 2019-04-23UTC: Auto merge of - Centril:rollup-akw4r85, r=Centril , , are likely the culprit.
Assigning as and removing .
Change:
let impl_candidates = self.find_similar_impl_candidates(trait_ref); self.report_similar_impl_candidates(impl_candidates, &mut err); } <del> self.suggest_change_mut( &obligation, &mut err, &trait_ref, points_at_arg, ); </del> <ins> // Changing mutability doesn't make a difference to whether we have // an `Unsize` impl (Fixes ICE in #71036) if !is_unsize { self.suggest_change_mut( &obligation, &mut err, &trait_ref, points_at_arg, ); } </ins> } // If this error is due to `!: Trait` not implemented but `(): Trait` is

Discussion:
I was playing with while I encountered a The simplest example I have producing the bug is Here is . It works if I remove the struct and put the directly in . The complete backtrace is <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
minimised ()
claim
Change:
self, bitcode_section_name, save_temp_bitcode, CodegenDiagnosticsStage, DiagnosticHandlers, }; use crate::errors::{ <del> DynamicLinkingWithLTO, LlvmError, LtoBitcodeFromRlib, LtoDisallowed, LtoDylib, </del> <ins> DynamicLinkingWithLTO, LlvmError, LtoBitcodeFromRlib, LtoDisallowed, LtoDylib, LtoProcMacro, </ins> }; use crate::llvm::{self, build_string}; use crate::{LlvmCodegenBackend, ModuleLlvm};

Discussion:
I'm trying to cross-compile the rust compiler to x86_64 on an M1 macOS machine with LTO enabled and ran into a compile error while building the stage2 compiler artifact: I also tried cross-compiling aarch64 on an Intel Mac and ran into the same issue. Here is the I used: It seems that is enabling LTO for proc-macro crates, but only when cross-compiling?
sorry for pinging, are there any updates on this issue? This bug is easily reproducible, and is preventing cross compiling the toolchain with LTO enabled.
I haven't had time to look into this, no. You can always disable LTO as a workaround.
This problem also appears when just the vendor of the target tripple changes (i.e. ).
Thank you for the additional feedback, will look into this issue in couple weeks.
Change:
<ins> #[prelude_import] use ::std::prelude::rust_2015::*; #[macro_use] extern crate std; // https://github.com/rust-lang/rust/issues/82329 // compile-flags: -Zunpretty=hir,typed // check-pass pub fn main() ({ (if (true as bool) ({ } as ()) else {match ((Some as fn(i32) -> Option<i32> {Option::<i32>::Some})((3 as i32)) as Option<i32>) { Some(a) => { } _ => { } }} as ()) } as ()) </ins>

Discussion:
I got this error on my code even though it did not have any in it. Also, it seems to only happen on crates. Just a is enough to reproduce it. rust playground: The bug also happens on and versions of the compiler. : <!-- 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 --
Oh, I think it's worth noting that if the code is refatored as: The bug ceases to happen.
I think duplicated of ?
this one doesn't need nightly to trigger
The code in works for me
right, because it's a different problem and only triggers with .
The issue seems to be that the gets desugared to a , which is currently unexpected in an branch. claim
Change:
/// assert_eq!(it.next().unwrap(), (&0, &1)); /// assert!(it.next().is_none()); /// ``` <ins> /// /// `zip` can provide similar functionality to `enumerate`: /// /// ``` /// for pair in "foo".chars().enumerate() { ///     println!("{:?}", pair); /// } /// /// for pair in (0..).zip("foo".chars()) { ///     println!("{:?}", pair); /// } /// ``` /// /// both produce the same output. </ins> #[inline] #[stable(feature = "rust1", since = "1.0.0")] fn zip<U: Iterator>(self, other: U) -> Zip<Self, U> {

Discussion:
Currently uses for counting. This is necessary when iterating over slices (probably the most common scenario). However, in general an iterator is not necessarily related to memory, so it may make more sense to use other integer types. It seems sensible to make generic over the integer type used for counting. This is backwards compatible, so it shouldn't break existing code. Would it be possible to make this change although is marked as stable?
nominating, like we've been doing for possible backompat-libs issue
Isn't it likely to break code where the integer type can't be inferred?
A little off-topic, but doesn't now do the exact same thing as ? We can just zip with to do with . =
Python has both of them as well, I think it is common enough to warrant its own iterator. On Tue, Feb 24, 2015, 09:30 Utkarsh Kukreti wrote:
E-needs-decision. cc 1.0 beta P-backcompat-libs.
Personally I'm inclined to keep things simple and just use here. In particular, to do otherwise would require basically adding an associated type to the trait, because we must have some way for generic wrappers like to reflect the index type of the things they are iterating over.
(The fact that zipping with provides an easy way to use other kinds of integers if you prefer is nice, though.)
Then I would honestly rather remove than having a crippled version.
itertools already has a generic (which is basically the same as zipping with ), you could possibly import that into libcore. Specifying the starting point adds another degree of customization and an obvious place to specify the integer type. For a generic I would worry it's too confusing and nonobvious how to specify the integer type to use. Standard .enumerate() is not crippled just because it's simple. It's one of a million possible iterator adaptors, and not all of them are going to be included in Rust by default.
I personally see as a common iterator adaptor which is expected in a library of iterators, so I would not want to remove it in favor of the less intuitive . I think it's fine to have the open ended range to count with an arbitrary integer, but I don't think we need to change as-is.
Well, then let's at least mention in 's documentation as the more flexible variant.

On Thu, Mar 19, 2015, 04:03 Alex Crichton wrote:
Ok after some more discussion the conclusion is that we probably don't want to make generic over integer types due to worries about inference and overcomplexity. This does seems like a worthwhile A-docs bug though, so I'm going to apply that label to ensure that we mention the alternative in the docs.
triage: P-high ()
Change:
fdata_sections, trap_unreachable, singlethread, <ins> asm_comments, </ins> ) };

Discussion:
clang -S produces nicely commented .s files. It would be nice if rustc did this too. e.g. simd shuffles are commented .loc directives have the corresponding line number comment .loc 1 4 25 isstmt 1 ## test.c:4:25 debug information is commented .byte 14 ## DWFORMstrp .byte 17 ## DWATlowpc .byte 1 ## DWFORMaddr .byte 18 ## DWAThighpc .byte 1 ## DWFORM_addr
There might be a or flag already for this. AFAIK what clang emits comes from LLVM.
This flag is already , should be usable (issue can be closed?):
Any reason not to make this the default?
Likely the fact that it may change the behavior (I don't actually know what that means but this seems like a valid assumption).
it looks like -Z asm-comments doesn't do this. MCOptions.AsmVerbose must be set to true for the assembler to emit them.
So it looks like -Zasm-comments isn't actually used anywhere based on what I can find in the source... or, rather, its uses are in methods that are themselves never called.
Yeah, to get comments I believe I needed to set a verbose flag in some llvm context. Clang does this by default and it would be nice if rustc did too.
IIUC without this neither the playground nor godbolt (compiler-explorer) can map assembly to lines of Rust source code.
Godbolt uses debug info AFAIK? Our debug info isn't always great but in general it's working, isn't it?
It seems like they just don't do it much. Godbolt uses directives in the assembly file, which rustc seems to generate correctly, sorry for the noise.
Change:
<ins> error[E0532]: expected unit struct/variant or constant, found tuple variant `MyEnum::Tuple` --> $DIR/issue-63983.rs:8:9 | LL |         MyEnum::Tuple => "", |         ^^^^^^^^^^^^^ did you mean `MyEnum::Tuple ( /* fields */ )`? error[E0532]: expected unit struct/variant or constant, found struct variant `MyEnum::Struct` --> $DIR/issue-63983.rs:10:9 | LL |         MyEnum::Struct => "", |         ^^^^^^^^^^^^^^ did you mean `MyEnum::Struct { /* fields */ }`? error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0532`. </ins>

Discussion:
Code Example (): <img width="805" alt="image" src="https://user-"Currently we provide a "do you mean..." for the but not for the . We probably should provide one for both.
Consider fixing Btw (which is a similar enhancement)
I'd like to work on this if it is still available.
go ahead! Ideally, you could turn the output into but just changing the tuple case would be enough.
I created a PR, could you please help review. I took a look at your suggestion of updating all the errors to , that seemed too many changes, not sure if it was necessary, so I just the tuple case.
Change:
<ins> // run-pass #![feature(adt_const_params, generic_const_exprs)] #![allow(incomplete_features, unused_variables)] struct F<const S: &'static str>; impl<const S: &'static str> X for F<{ S }> { const W: usize = 3; fn d(r: &[u8; Self::W]) -> F<{ S }> { let x: [u8; Self::W] = [0; Self::W]; F } } pub trait X { const W: usize; fn d(r: &[u8; Self::W]) -> Self; } fn main() {} </ins>

Discussion:
: <details<summaryerror output</summary</details
Rust playground:
Have you been able to reproduce this ICE with the latest nightly?
Playground link is not failing, I guess it's a good sign.
No longer ICEs since

The code below will trigger an ICE on the latest nightly build This is as small as i could make it while still triggering the error <!-- 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
Also occurs on stable! Regression from 1.50 to 1.51 modify labels: -requires-nightly +regression-from-stable-to-stable
Bisected: searched nightlies: from nightly-2020-01-01 to nightly-2021-04-29 regressed nightly: nightly-2021-01-18 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.0</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailsRegressed PR is , cc
See and
just because something is gated doesn't mean it can't crash on stable ;) Use the above code and try to build it on the playground or compile it with a stable compiler, it will ICE.
We briefly discussed this on . I'd revert some labels here because we think this is a nightly-only issue due to the unstable feature. The fact that it compiles and reproduces on stable is kind of misleading because it's the that allows that. Makes sense? modify labels: +requires-nightly -regression-from-stable-to-stable +P-medium
sure enough ;) but just to be clear, even without this results in an ICE on stable
Okay so this is a bit complicated. Because while this does has , is still ICEs on stable. That said, not including the feature gate doesn't ICE. Given that, I think the current labels are appropriate, except maybe . It is technically a stable to stable regression, but it requires a feature to ICE, and I'm not sure that's the spirit of what that label is intended to track.
agreed on the labels, I've got the context partially wrong here. modify labels: -requires-nightly
With this also doesn't ICE
No longer ICEs since as far as I could tell with various combinations of the new feature gates
Change:
use rustc_errors::emitter::{DynEmitter, Emitter, HumanEmitter}; use rustc_errors::translation::Translate; use rustc_errors::{ <del> ColorConfig, DiagCtxt, Diagnostic, DiagnosticBuilder, Level as DiagnosticLevel, </del> <ins> ColorConfig, DiagCtxt, Diagnostic, DiagnosticBuilder, ErrorGuaranteed, Level as DiagnosticLevel, </ins> }; use rustc_session::parse::ParseSess as RawParseSess; use rustc_span::{

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc
Probably a duplicate of , and hopefully will be fixed by .
no, I checked, while is fixed, this one isn't :(
Change:
} declare_lint! { <del> /// The `unreachable_pub` lint triggers for `pub` items not reachable from /// the crate root. </del> <ins> /// The `unreachable_pub` lint triggers for `pub` items not reachable from other crates - that /// means neither directly accessible, nor reexported, nor leaked through things like return /// types. </ins> /// /// ### Example ///

Discussion:
This is a tracking issue for the RFC "Type privacy and private-in-public lints " (rust-lang/rfcs). Steps: [ ] Implement the RFC (cc ) [ ] Adjust documentation ([see instructions on forge][doc-guide]) [ ] Stabilization PR ([see instructions on forge][stabilization-guide]) [stabilization-guide]: [doc-guide]: Unresolved questions: [ ] It's not fully clear if the restriction for associated type definitions required for type privacy soundness, or it's just a workaround for a technical difficulty. [ ] Interactions between macros 2.0 and the notions of reachability / effective visibility used for the lints are unclear. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Oops - I didn't mean for that to un-assign you. Is there a way to prevent these lints from becoming insta-stable? Would it make sense to put them behind a feature gate?
Perhaps we could only fire the lints if an unstable compiler flag (maybe ) is passed? This would still make the lint names insta-stable, though.
in core ffi There is a fixme about , how to fixes that?
By implementing this RFC, I guess. Until that workarounds like this sealed trait will need to be used.
Where is the impl, the RFC is already accepted...
An RFC being accepted just means the feature can be implemented, not that it has been implemented. It doesn't even mean that implementing it is a priority. I believe there has been more discussion of this RFC over at as well as other issues that I can't seem to track down right now.
Hello! I know y'all are busy, but I'm curious if there's an update, particularly on for Voldemort Types - which I'd love to see. I was actually a bit surprised to find that it wasn't included in the existing lint. Appreciate the work that y'all are doing, especially who seems to have put in a lot of legwork.
The tentative plan is that will work on this in March-May.
Cool! Good luck! I'm happy to be a guinea pig to try it out or do code review if that would be helpful.
This issue should be closed by Two follow up issues about improving the effective visibility tables
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-61106.rs:3:9 | LL |     foo(x.clone()); |         ^^^^^^^^^ |         | |         expected &str, found struct `std::string::String` |         help: consider borrowing here: `&x` | = note: expected type `&str` found type `std::string::String` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
On type mismatch with a suggestion to borrow in order to dereference a into a , we should notice unnecessary calls: and suggest their removal: From
Change:
<del> // aux-build: foreign-generic-mismatch-with-const-arg.rs extern crate foreign_generic_mismatch_with_const_arg; fn main() { foreign_generic_mismatch_with_const_arg::test::<1>(); //~^ ERROR function takes 2 generic arguments but 1 generic argument was supplied } </del>

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. --cc still crashes after <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Sigh, yeah, this is just the same bug but for lifetime params. I'll fix it, shouldn't be too hard. claim
Hey, , thanks for getting this fixed! Unfortunately, I seem to be running into the same issue (or a very similar one) using the latest nightly, and I've not been able to create a standalone reproducer: <details<summaryBacktrace</summary<p</p</detailsSorry if this is the wrong place to be reporting this ICE, but I wasn't sure whether to file a new issue or maybe get one of the resolved issues re-opened. Thank you!
Change:
//         ^ elided type as this type argument was the same in both sides let type_arguments = sub1.types().zip(sub2.types()); let regions_len = sub1.regions().collect::<Vec<_>>().len(); <del> for (i, (ta1, ta2)) in type_arguments.enumerate() { </del> <ins> for (i, (ta1, ta2)) in type_arguments.take(len).enumerate() { </ins> let i = i + regions_len; if ta1 == ta2 { values.0.push_normal("_");

Discussion:
In , adding an parameter to the type, that defaults to induces changes to UI tests that are indicative of something that seemed to need improvement in the compiler, namely that when you have a type , errors should present instead of when they can. It turns out, the compiler does. But not consistently. The following is derived from : () This yields the following errors: See how it prints instead of the (imho) desired , but , not .
This all stems from the fact that in some cases, types are just printed out by formatting the instances, while in other cases, there is manual machinery to highlight parts of the type that handle things, and that doesn't have the default-param elimination that has.