jiebi/CodeConvo huggingface dataset:
Code change:
tcx: TyCtxt<'tcx>, // typeck errors have subpar spans for opaque types, so delay error reporting until borrowck. ignore_errors: bool, <del> origin: OpaqueTyOrigin, </del> ) -> Self { let OpaqueTypeKey { def_id, substs } = opaque_type_key;

Related discussion:
text: Here is an example which uses a RPIT on a borrowed type in three different ways: IMO this is perfectly reasonable code and (EDIT: see below). On stable () we have the following: And on beta () and nightly () we get some additional errors: EDIT: On second thought, I guess the first error (on stable) is reasonable, since we are actually returning a in that case. If you either use in the body or in the return type then the error goes away. But the second error is still a regression. It most recently worked on: rustc 1.66.0 ( 2022-12-12) : modify labels: +regression-from-stable-to-beta -regression-untriaged
This is . Cc It is related to the invariance: Another case that doesn't rely on member constraints in the second function and yields a different error message: I also found a distantly related regression that doesn't require invariance. It looks like a missed subtyping opportunity:
Another version using TAIT: At this point there are two classes of regression: The first is related to the fact that and the the second requires more subtyping relations. label I-types-nominated T-types T-compiler
WG-prioritization assigning priority (). label -I-prioritize +P-critical
From beta crater: https://crater- https://crater- https://crater- https://crater- https://crater-
unnominating as it will get fixed by which is approved again. Have to try to get this into beta though, only have 1 more day for that
Code change:
//!    in this case, if one uses the format string `{<arg>:<spec>.*}`, then the `<arg>` part refers //!    to the *value* to print, and the `precision` must come in the input preceding `<arg>`. //! <del> //! For example, these: </del> <ins> //! For example, the following calls all print the same thing `Hello x is 0.01000`: </ins> //! //! ``` <del> //! // Hello {arg 0 (x)} is {arg 1 (0.01) with precision specified inline (5)} </del> <ins> //! // Hello {arg 0 ("x")} is {arg 1 (0.01) with precision specified inline (5)} </ins> //! println!("Hello {0} is {1:.5}", "x", 0.01); //! <del> //! // Hello {arg 1 (x)} is {arg 2 (0.01) with precision specified in arg 0 (5)} </del> <ins> //! // Hello {arg 1 ("x")} is {arg 2 (0.01) with precision specified in arg 0 (5)} </ins> //! println!("Hello {1} is {2:.0$}", 5, "x", 0.01); //! <del> //! // Hello {arg 0 (x)} is {arg 2 (0.01) with precision specified in arg 1 (5)} </del> <ins> //! // Hello {arg 0 ("x")} is {arg 2 (0.01) with precision specified in arg 1 (5)} </ins> //! println!("Hello {0} is {2:.1$}", "x", 5, 0.01); //! <del> //! // Hello {next arg (x)} is {second of next two args (0.01) with precision </del> <ins> //! // Hello {next arg ("x")} is {second of next two args (0.01) with precision </ins> //! //                          specified in first of next two args (5)} //! println!("Hello {} is {:.*}",    "x", 5, 0.01); //! <del> //! // Hello {next arg (x)} is {arg 2 (0.01) with precision </del> <ins> //! // Hello {next arg ("x")} is {arg 2 (0.01) with precision </ins> //! //                          specified in its predecessor (5)} //! println!("Hello {} is {2:.*}",   "x", 5, 0.01); //! <del> //! // Hello {next arg (x)} is {arg "number" (0.01) with precision specified </del> <ins> //! // Hello {next arg ("x")} is {arg "number" (0.01) with precision specified </ins> //! //                          in arg "prec" (5)} //! println!("Hello {} is {number:.prec$}", "x", prec = 5, number = 0.01); //! ``` //! <del> //! All print the same thing: //! //! ```text //! Hello x is 0.01000 //! ``` //! </del> //! While these: //! //! ```

Related discussion:
text: Was just trying to read through std::fmt to understand how format values to a particular decimal point. I came across this set of examples, which don't do a good job of explaining the output of each, so it's difficult to visually pattern match what I type in to what comes out:
Sorry for the mess :sweat_smile: I guess it is clearer now.
Code change:
pub use idx::Idx; pub use rustc_index_macros::newtype_index; pub use slice::IndexSlice; <ins> #[doc(no_inline)] </ins> pub use vec::IndexVec; /// Type size assertion. The first argument is a type and the second argument is its expected size.

Related discussion:
text: We have some relative links in doc, e.g., the link of in the comments for : but we will get the page if we click it in , which is re-exported. So I think we can fix this by two ways: 't use relative path in rustc doc 't generate new link for re-exported items, use the same links with the original definition but for the second option, we may have private middle mods, so it may be not a solution. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cc
I'm thinking of tackling this issue, is this Issue aimed at removing this invalid path once and for all? (Sorry if I'm wrong as I'm trying to contribute for the first time)
claim
Hi just checking if you are still working on the issue? If so, apologies please ignore this. Otherwise I'm happy to take over. Thanks
take it
Code change:
<ins> fn foo<T>(t: T) { || { t; t; }; //~ ERROR: use of moved value } fn main() {} </ins>

Related discussion:
text: I encounter an ICE: with rustc 1.41.0-nightly ( 2019-12-06) running on x86_64-pc-windows-msvc when compiling The Stable compiler outputs But Nightly crashed.
Confirmed on Linux too. <details<summaryBacktrace</summary</details
Reduced slightly:
cc
Really reduced: This comes from this unwrap: The used should be
Code change:
placeholder_type_error(tcx, None, &[], visitor.0, false); } <del> hir::TraitItemKind::Type(_, None) => {} </del> <ins> hir::TraitItemKind::Type(_, None) => { // #74612: Visit and try to find bad placeholders // even if there is no concrete type. let mut visitor = PlaceholderHirTyCollector::default(); visitor.visit_trait_item(trait_item); placeholder_type_error(tcx, None, &[], visitor.0, false); } </ins> }; tcx.ensure().predicates_of(def_id);

Related discussion:
text: First time filing a bug report, apologies if i missed anything or if this is a duplicate. Encountered this bug while writing some non-sensical associated function types. Searched around for any similar issues and the closest i found was , seems closely related? Minimal example: Playground link: The ICE happens on all channels it seems
Yes, I think so too. The snippet is rejected as expected on 1.42 but ICE occurs instead since 1.43.
Assigning as and removing .
Code change:
<ins> // check-pass // ignore-emscripten no llvm_asm! support #![feature(llvm_asm)] pub fn boot(addr: Option<u32>) { unsafe { llvm_asm!("mov sp, $0"::"r" (addr)); } } fn main() {} </ins>

Related discussion:
text: rustc+cargo 1.40.0 Debian testing packages report the following ICE (which does not go away after a cargo clean): It can be reproduced by trying to build against
Can you try this on nightly?
Once the ICEBreakers-CleanupCrew is announced (which I think will be happening very soon), we should advertise this bug on it (at least the reduction to MCVE part of it); see
triage: P-high for initial investigation (i.e. identifying actual severity), removing nomination.
ping icebreakers-cleanup-crew
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://rust- cc
Note that when I had a go at building on my Mac laptop, it failed with this message: This is due to in the source crate: So if you are on a Mac laptop, it may or may not be worth your effort to investigate this. (It is probably easy to work around, but I figure I'd let people know up front.)
Oops, right, you'll want to just drop that line. It shouldn't have any other effect, its only there due to (at least previously, based on my super-cursory read) libstd calling regular fsync() on OSX, which historically, well, didn't fsync.
I looked at this a bit more. I see the ICE on stable and beta. I do not see the ICE on nightly.
Code change:
<ins> // check-pass // ignore-emscripten no llvm_asm! support #![feature(llvm_asm)] pub fn boot(addr: Option<u32>) { unsafe { llvm_asm!("mov sp, $0"::"r" (addr)); } } fn main() {} </ins>

Related discussion:
text: On nightly, I instead get the following error: <details<summaryClick here to see error diagnostics</summary</details
Possibly associated: Possibly associated: I am not seeing the ICE in: searched nightlies: from nightly-2019-10-01 to nightly-2019-11-01 regressed nightly: nightly-2019-10-08 searched commits: from to regressed commit: source code: built against <details<summaryCOLLAPSIBLE ERROR STACKTRACE</summary<p</detailssearched nightlies: from nightly-2019-11-01 to nightly-2020-01-31 fixed nightly: nightly-2019-12-08 searched commits: from to fix commit: source code: built against Possibly here: -
Reduced for in the crate (still depends on ):
This is happening somewhere in item-bodies checking, if I remove the body of with the error goes away.
Ok, I don't have more time to spend on this, I pushed some deletions to
Got it down to two files, but they have to be in different crates: : :
A little smaller: : : <details<summarybacktrace</summary</details
This is a duplicate of , judging by the error message and the fact that I just confirmed as the fixing commit for the reduced example that I created over there. modify labels to -E-needs-mcve.
Code change:
<ins> // check-pass // ignore-emscripten no llvm_asm! support #![feature(llvm_asm)] pub fn boot(addr: Option<u32>) { unsafe { llvm_asm!("mov sp, $0"::"r" (addr)); } } fn main() {} </ins>

Related discussion:
text: Take the following code: Attempting to compile this results in the following: I think the compiler should fail with something along the lines of "you attempted to use a complex type () where I expected an immediate".
edit: not sure if these symptoms are the same, but here's what I stumbled across. The following code generates a similar result for me: The and struct seem to be required, else the ICE is not triggered. Output
No longer reproduces:
Code change:
<ins> // check-pass // ignore-emscripten no llvm_asm! support #![feature(llvm_asm)] pub fn boot(addr: Option<u32>) { unsafe { llvm_asm!("mov sp, $0"::"r" (addr)); } } fn main() {} </ins>

Related discussion:
text: We handle intrinsics in an odd way, we "inline" them in the current crate, and this might be a symptom of that twisted logic.
intrinsic-ABI functions should probably be disallowed as function pointers. That is, you should only be allowed to call them. This is the current situation, as calls to intrinsics actually just generate code at the call site.
That's not the problem, really, I believe we already have code to generate the shims. The problem is that we don't resolve intrinsics sanely and we rely on the ABI in the type, instead of always dealing with the paths to them and whatnot.
I don't think we have code for creating the shims, even. It's more that the ABI isn't actually defined anywhere, and we use an alternate callee to avoid generating an actual call.
We haven't had code for generating shims around intrinsics for a long time. As alludes to, this is because in almost all cases the actual function would be one or two instructions long. This is consistent with how C/C++ compilers handle intrinsics, generating code inline. Best I can tell, whether or not a given intrinsic can be used as a function in C is dependent on the intrinsic in question.
No longer ICEs ()
It requires now.
Ah, ok. Still no longer ICEs, but fails with a linker error (), if the distinction matters.
I think this has been fixed -- marking as E-needstest. Did you mean to self-assign this?
This seems like it could be made into an easy issue for newcomers.
This is now caught by .
Code change:
<ins> // check-pass // ignore-emscripten no llvm_asm! support #![feature(llvm_asm)] pub fn boot(addr: Option<u32>) { unsafe { llvm_asm!("mov sp, $0"::"r" (addr)); } } fn main() {} </ins>

Related discussion:
text: rustc just crashes with no useful errors. I guess you're not supposed to be able to do this anyway and it works if either are const instead of static but it shouldn't crash. Tested with latest nightly and 1.0.0-beta.2 on windows 64-bit.
No longer crashes:
E-needstest.
Triage: not aware of any tests being .
It seems that the E0394 error was removed in and the tests were moved from compile-fail and ui/error-codes to run-pass.
Code change:
<ins> error[E0658]: attributes on expressions are experimental --> $DIR/issue-88476.rs:20:13 | LL |     let x = #[rustc_capture_analysis] move || { |             ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #15701 <https://github.com/rust-lang/rust/issues/15701> for more information = help: add `#![feature(stmt_expr_attributes)]` to the crate attributes to enable error[E0658]: attributes on expressions are experimental --> $DIR/issue-88476.rs:47:13 | LL |     let c = #[rustc_capture_analysis] move || { |             ^^^^^^^^^^^^^^^^^^^^^^^^^ | = note: see issue #15701 <https://github.com/rust-lang/rust/issues/15701> for more information = help: add `#![feature(stmt_expr_attributes)]` to the crate attributes to enable error: First Pass analysis includes: --> $DIR/issue-88476.rs:20:39 | LL |       let x = #[rustc_capture_analysis] move || { |  _______________________________________^ LL | | LL | | LL | | ...  | LL | | LL | |     }; | |_____^ | note: Capturing f[(0, 0)] -> ImmBorrow --> $DIR/issue-88476.rs:25:26 | LL |         println!("{:?}", f.0); |                          ^^^ error: Min Capture analysis includes: --> $DIR/issue-88476.rs:20:39 | LL |       let x = #[rustc_capture_analysis] move || { |  _______________________________________^ LL | | LL | | LL | | ...  | LL | | LL | |     }; | |_____^ | note: Min Capture f[] -> ByValue --> $DIR/issue-88476.rs:25:26 | LL |         println!("{:?}", f.0); |                          ^^^ error: First Pass analysis includes: --> $DIR/issue-88476.rs:47:39 | LL |       let c = #[rustc_capture_analysis] move || { |  _______________________________________^ LL | | LL | | LL | | ...  | LL | | LL | |     }; | |_____^ | note: Capturing character[(0, 0)] -> ImmBorrow --> $DIR/issue-88476.rs:52:24 | LL |         println!("{}", character.hp) |                        ^^^^^^^^^^^^ error: Min Capture analysis includes: --> $DIR/issue-88476.rs:47:39 | LL |       let c = #[rustc_capture_analysis] move || { |  _______________________________________^ LL | | LL | | LL | | ...  | LL | | LL | |     }; | |_____^ | note: Min Capture character[(0, 0)] -> ByValue --> $DIR/issue-88476.rs:52:24 | LL |         println!("{}", character.hp) |                        ^^^^^^^^^^^^ error: aborting due to 6 previous errors For more information about this error, try `rustc --explain E0658`. </ins>

Related discussion:
text: I tried this code: This does not issue a warning for , however it fails to compile with enabled: I would expect to give a suggestion to add . Found in the 2021 crater run for: I'm uncertain if this is a duplicate of or , they seem very similar, but this case is specific to implementing Drop. : cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
claim
Code change:
build::CondBr(bcx, cond.immediate(), lltrue, llfalse, DebugLoc::None); } <del> mir::Terminator::Switch { .. } => { unimplemented!() </del> <ins> mir::Terminator::Switch { ref discr, ref adt_def, ref targets } => { let adt_ty = bcx.tcx().lookup_item_type(adt_def.did).ty; let represented_ty = adt::represent_type(bcx.ccx(), adt_ty); let discr_lvalue = self.trans_lvalue(bcx, discr); let discr = adt::trans_get_discr(bcx, &represented_ty, discr_lvalue.llval, None); // The else branch of the Switch can't be hit, so branch to an unreachable // instruction so LLVM knows that // FIXME it might be nice to have just one such block (created lazilly), we could // store it in the "MIR trans" state. let unreachable_blk = bcx.fcx.new_temp_block("enum-variant-unreachable"); build::Unreachable(unreachable_blk); let switch = build::Switch(bcx, discr, unreachable_blk.llbb, targets.len()); assert_eq!(adt_def.variants.len(), targets.len()); for (adt_variant, target) in adt_def.variants.iter().zip(targets) { let llval = adt::trans_case(bcx, &*represented_ty, adt_variant.disr_val); let llbb = self.llblock(*target); build::AddCase(switch, llval, llbb) } </ins> } mir::Terminator::SwitchInt { ref discr, switch_ty, ref values, ref targets } => {

Related discussion:
text: The Switch terminator, which is used in pattern matching, is currently unimplemented in MIR. This terminator should load the discriminant from an lvalue and branch to the appropriate basic block target based on what is found there. It has to integrate with the code.
Code change:
<ins> // Copyright 2017 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. #![feature(rustc_attrs)] use std::fmt; // CoerceUnsized is not implemented for tuples. You can still create // an unsized tuple by transmuting a trait object. fn any<T>() -> T { unreachable!() } #[rustc_error] fn main() { //~ ERROR compilation successful let t: &(u8, fmt::Debug) = any(); println!("{:?}", &t.1); } </ins>

Related discussion:
text: This code: produces a helpful error message: But the analogous code using a : gives an error which doesn't point at the binding :
This is fixed today. I'm going to mark as E-needstest since it feels like the kind of thing that's easy to regress on -- a UI test would be best here.
Code change:
<ins> // Copyright 2017 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. #![feature(rustc_attrs)] use std::fmt; // CoerceUnsized is not implemented for tuples. You can still create // an unsized tuple by transmuting a trait object. fn any<T>() -> T { unreachable!() } #[rustc_error] fn main() { //~ ERROR compilation successful let t: &(u8, fmt::Debug) = any(); println!("{:?}", &t.1); } </ins>

Related discussion:
text: Before , this caused an LLVM error Afterwards, this causes an ICE (the rustc size is the correct one):
I am now getting a segfault in LLVM, but I'm uncertain whether that's actually the case, or just a local build problem.
Looks like called on a NULL pointer? Probably some missing check that something is indeed unsized, with actual metadata to go alongside it.
Appears to be fixed today. E-needstest.
It seems that a better diagnostic output is needed:
Why? I believe it's implemented as a feature now (maybe it should be ?).
it's unrelated to this issue, but rather to 's solution, merits at least a clarifying label pointing at the , as otherwise the compiler output makes you look at the following line exclusively, which isn't the cause for the . I know it definitely confused me_ :) Back to this issue, yes, the test in should be .
Code change:
<ins> // Copyright 2017 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. #![feature(rustc_attrs)] use std::fmt; // CoerceUnsized is not implemented for tuples. You can still create // an unsized tuple by transmuting a trait object. fn any<T>() -> T { unreachable!() } #[rustc_error] fn main() { //~ ERROR compilation successful let t: &(u8, fmt::Debug) = any(); println!("{:?}", &t.1); } </ins>

Related discussion:
text: Triage: this no longer ICEs. <details<summaryMeta</summary: rustc 1.16.0 ( 2017-03-10) binary: rustc commit-hash: commit-date: 2017-03-10 host: x86_64-pc-windows-gnu release: 1.16.0 LLVM version: 3.9 </details
Code change:
None } Err(ErrorHandled::TooGeneric) => { <del> span_bug!(tcx.def_span(expr_did), "enum discriminant depends on generic arguments",) </del> <ins> tcx.sess.delay_span_bug( tcx.def_span(expr_did), "enum discriminant depends on generic arguments", ); None </ins> } } }

Related discussion:
text: The following ICE's on stable, beta and nightly: (notice the was NOT closed) <details<summaryBacktrace:</summary</details
Oh, this works with other types as well, except the messages are different ICE's with:
ICE's with:
Its worth nothing explicitly that: these ICE's are happening after we do issue a diagnostic for the parsing error If you address the parsing error (presumably in the same manner that the parser is auto-correcting to make further progress), the ICE goes away
triage: P-medium. Removing nomination.
Triage: The first example still ICEs in MIR building The second and third examples don't ICE anymore and need tests (without closing this issue!).
cc
Code change:
unsafe { Some((self.a.__iterator_get_unchecked(i), self.b.__iterator_get_unchecked(i))) } <del> } else if A::MAY_HAVE_SIDE_EFFECT && self.index < self.a.size() { </del> <ins> } else if A::MAY_HAVE_SIDE_EFFECT && self.index < self.a_len { </ins> let i = self.index; self.index += 1; self.len += 1;

Related discussion:
text: Here is called for potential side effects until , ignoring however that it could have already been called in with those indexes. that demonstrates how this can be exploited to get two mutable references to the same data and cause an use-after-free bug.
Assigning as part of the .
The gift that keeps on giving Maybe it is time to get rid of as it exists today and replace it with a ? One that imposes the additional requirement on the caller that it must bring the iterator back into a safe state after it is done iterating. The upside would be eliminating a lot of code in and enabling the same optimization for and similar sources. While the downside would be that external iteration (i.e. loops and manual calls to ) would cease to benefit from optimizations and only internal iteration methods (including ) would continue to do so.
I don't know, I feel like that would just make more complex to upheld the invariants. IMO a good improvement over the current would be separating forward and backward iteration, this way it becomes easier to keep track of the state and I think would also make it possible to implement them for
I don't see how separating the forward and backward state would help with a drop implementation. The issue is that the source () currently does not have access to that state, instead the consumer drives the iteration by direct access through and never informs the source about it.
It would help because it allows the source iterator to keep track of its state by updating it when the method is called. Anyway, looks like someone already and it resulted in worse optimizations, but maybe LLVM got better in the meantime, or maybe that implementation could have been better. Anyway I don't think this is the right place to discuss this, a topic on zulip would probably be better.
https://rust-