jiebi/CodeConvo huggingface dataset:
Change:
stmts: &'tcx [hir::Stmt]) -> Vec<StmtRef<'tcx>> { let mut result = vec![]; <del> let opt_def_id = cx.tcx.hir.opt_local_def_id(block_id); </del> for (index, stmt) in stmts.iter().enumerate() { <del> let opt_dxn_ext = opt_def_id.and_then(|def_id| { cx.tcx.region_maps(def_id).opt_destruction_extent(stmt.node.id()) }); </del> <ins> let opt_dxn_ext = cx.region_maps.opt_destruction_extent(stmt.node.id()); </ins> match stmt.node { hir::StmtExpr(ref expr, id) | hir::StmtSemi(ref expr, id) => {

Discussion:
The following code compiles to MIR without any (this is right before the pass): Cc
Cc
Indeed, even the shows no for that borrow. Looking further now.
Very weird: It seems like at the time that control reaches this statement in , there is no destruction scope attached to it...? still looking... (I'm not aware of a place where a destruction scope would be later...)
A ha! The destruction scope exists, but during the HIR -HAIR translation, we fail to find it, because the way we look up the destruction scope is with some code that looks like this: but the that we got for that is , so the lookup doesn't have a chance of working. Now to figure out what is returning here (or if we perhaps should be using a different key for the lookup?)
that I should not be attempting to do in the first place here (which then goes south when I fail to find the appropriate to use), because the itself now carries the appropriate directly, thanks to (specifically ) Will fix!
Change:
Rc::new(Vec::from_slice(impl_poly_type.generics.type_param_defs()).append( new_method_ty.generics.type_param_defs())), region_param_defs: <del> impl_poly_type.generics.region_param_defs.clone() </del> <ins> Rc::new(Vec::from_slice(impl_poly_type.generics.region_param_defs()).append( new_method_ty.generics.region_param_defs())) </ins> }; let new_polytype = ty::ty_param_bounds_and_ty { generics: new_generics,

Discussion:
Not exactly sure what the minimal failing test case is yet.
I think that I was running an out of date rustc. I don't think that this is a problem on master.
Actually, I hit this on rustc that I just built from master.
I talked to and he gave me access to his codebase, which I used to narrow down: Converting to a normal trait method and implementing it for stops the ICE. cc
Change:
let block_info = match kind { CodeBlockKind::Fenced(ref lang) => { if lang.is_empty() { <del> LangString::all_false() </del> <ins> Default::default() </ins> } else { LangString::parse( lang,

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:
<ins> //@ needs-sanitizer-cfi //@ compile-flags: -Ccodegen-units=1 -Clto -Ctarget-feature=-crt-static -Zsanitizer=cfi //@ no-prefer-dynamic //@ only-x86_64-unknown-linux-gnu //@ build-pass // See comment below for why this test exists. trait Tr<U> { type Projection; } impl<F, U> Tr<U> for F where F: Fn() -> U { type Projection = U; } fn test<B: Tr<U>, U>(b: B) -> B::Projection { todo!() } fn main() { fn rpit_fn() -> impl Sized {} // When CFI runs, it tries to compute the signature of the call. This // ends up giving us a signature of: //     `fn test::<rpit_fn, ()>() -> <rpit_fn as Tr<()>>::Projection`, // where `rpit_fn` is the ZST FnDef for the function. However, we were // previously using a Reveal::UserFacing param-env. This means that the // `<rpit_fn as Tr<()>>::Projection` return type is impossible to normalize, // since it would require proving `rpit_fn: Fn() -> ()`, but we cannot // prove that the `impl Sized` opaque is `()` with a user-facing param-env. // This leads to a normalization error, and then an ICE. // // Side-note: // So why is the second generic of `test` "`()`", and not the // `impl Sized` since we inferred it from the return type of `rpit_fn` // during typeck? Well, that's because we're using the generics from the // terminator of the MIR, which has had the RevealAll pass performed on it. let _ = test(rpit_fn); } </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</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label A-sanitizers
Change:
<ins> error: meta-variable `id1` repeats 2 times, but `id2` repeats 3 times --> $DIR/issue-61033-2.rs:8:10 | LL |           $( |  __________^ LL | |             $id1 + $id2 // $id1 and $id2 may repeat different numbers of times LL | |         )* | |_________^ error: aborting due to previous error </ins>

Discussion:
Given this test file: stable Rust errors like this: while on 1.36.0-nightly ( 2019-05-21) running on x86_64-unknown-linux-gnu:
caused by cc
Yay, we have a test case.
Hmm... interesting... yeah, I guess we have a test case. I will open a PR to revert and add the test case. Thanks ! But this raises a bigger point that has been growing on me for a while now: there are a ton of checks that are currently only done at macro invocation time (or are not done at all) that really would make more sense to do a macro definition time. Checking that the Kleene operator used in the body is the same as that in the matcher Checking that all meta-variables used in the body are defined and in scope Checking that all meta-variables used in the body are repeating at the right depth Checking that the body of a macro is actually valid rust syntax (to the extent that we can, anyway) So far, I have been holding off on attempting to fix these because they could involve building a whole language, and it seems that at some point we want to just use macros... Thoughts?
Opened
there are a ton of checks that are currently only done at macro invocation time (or are not done at all) that really would make more sense to do a macro definition time. If the defined macro produces an error with any possible input, then we should probably report it at definition time, at least as a quality of implementation measure (perhaps as a warning for a start). I have more confidence in reporting errors related to the macro definition language itself (meta-variables, repetitions, etc.), than in errors for produced tokens (which are not necessarily supposed to be Rust code, with eager expansion they may be consumed by another macro, for example).
Ok, makes sense. I will open another issue with these items so we can track them.
Change:
<ins> Function name: no_spans_if_not::main Raw bytes (9): 0x[01, 01, 00, 01, 01, 0b, 01, 02, 02] Number of files: 1 - file 0 => global file 1 Number of expressions: 0 Number of file 0 mappings: 1 - Code(Counter(0)) at (prev + 11, 1) to (start + 2, 2) </ins>

Discussion:
The immediate symptoms of were fixed by , but some users reported that their builds now encounter another coverage-related ICE:
label +T-compiler +A-code-coverage
This ICE does not occur on current stable/beta, but does occur on nightly. label +regression-from-stable-to-nightly
(This will be fixed by , which is awaiting review.)
WG-prioritization assigning priority (). label -I-prioritize +P-high
Change:
} return None; } <del> PathResult::NonModule(_) => { if no_ambiguity { </del> <ins> PathResult::NonModule(partial_res) => { if no_ambiguity && partial_res.full_res() != Some(Res::Err) { // Check if there are no ambiguities and the result is not dummy. </ins> assert!(import.imported_module.get().is_none()); } // The error was already reported earlier.

Discussion:
Exact code unknown code. The error was generated by using . Rerunning after did not fix this. Did not resolve this yet at the time of writing this. This might be related to: But I think this was because I compiles first and got this error: This was expected to give an error (needed to be ) <details<summary<strongFull backtrace on the fist check:</strong</summary<p</p</details: Problem persists after updating to last nightly: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace (After trying to recheck it)</strong</summary<p</p</details
I just found out the problem exists because of: If I comment out that line it will not report an internal error anymore. I had a function but I also use the crate  I now renamed the function but still getting errors. So it is likely because of a ambiguity issue. Trying to reproduce it in minimal code example, but not yet been able to do so.
After some testing a narrowed it down to the following: : : My guess why this fails: The macro uses inside of it. But when I try to export this it can not find it. commenting out/removing any line will give a normal compile error. I hope this helps to find out the problem. The error always happens and can thus be reliably reproduced. I tested this on latest nightly too:
reduced:
Hi can you assign it to me? I would like to give it a try and solve it.
Change:
<del> diff --git a/include/libunwind.h b/include/libunwind.h index c5b9633..1360eb2 100644 --- a/include/libunwind.h +++ b/include/libunwind.h @@ -151,8 +151,8 @@ enum { UNW_X86_ECX = 1, UNW_X86_EDX = 2, UNW_X86_EBX = 3, -  UNW_X86_EBP = 4, -  UNW_X86_ESP = 5, +  UNW_X86_ESP = 4, +  UNW_X86_EBP = 5, UNW_X86_ESI = 6, UNW_X86_EDI = 7 }; </del>

Discussion:
Causing our builds to fail. I have no idea why ;_;
According to https://travis- We have 30GB of disk space 23 of which is available on the start of a build: ` At the end of the build, the dir is 23 GB: And such, we're filling up.
cc
According to https://travis- we start out with 5/30GB taken up
Word from travis is that we can't increase disk size right now.
According to the run-pass output directory is 17GB
"Hello world" for musl is 3.5 MB. With 2.8k tests and three separate targets being tested, that's ~30GB. That's where the space is going.
1MB of that 3.5 is debuginfo
Change:
<del> use crate::spec::{base, CodeModel, Target, TargetOptions}; </del> <ins> use crate::spec::{base, Target, TargetOptions}; </ins> pub fn target() -> Target { Target {

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. --I tried this code: I expected to see this happen: outputs version info Instead, this happened: dead loop in entry function. <!-- 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. --:
label O-loongarch
That would be due to the LLVM 18 upgrade.
Yeah. It seems that the CI loongarch64-unknown-linux-gnu ld does not handle relocations correctly.
There is no version of crosstool-ng that supports , I'll revert the until the issue is resolved.
Oooops. Is this communicated with crosstool-ng maintainers?
But maybe crosstool-ng maintainers can't act as well due to the incompatibility between GCC 13.2 and Binutils 2.42 (loongson-community/discussions) :(. I'm not sure how to fix such an incompatibility...
Not yet. binutils 2.42 in progress:
is merged recently that bumped the LoongArch binutils to 2.42, so can we try again?
Yes, with merged, we can retry .
Today's nightly is built off of , which contains and does work: And the code model is indeed in use: So this issue is finally resolved. Thanks for everyone involved!
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <ins> #![feature(optin_builtin_traits)] </ins> pub mod bar { use std::marker;

Discussion:
I suspect that we may want more experience with this syntax before freezing it, but I may also be misremembering! cc cc
triage: I-nominated
I believe you're right. I'll work on a fix for this. Here's a test case:
0 beta, P-backcompat-lang.
Change:
below.) If you're on Windows, please download either the [32-bit <del> installer](https://static.rust-lang.org/dist/rust-nightly-i686-pc-mingw32.exe) </del> <ins> installer](https://static.rust-lang.org/dist/rust-nightly-i686-w64-mingw32.exe) </ins> or the [64-bit installer](https://static.rust-lang.org/dist/rust-nightly-x86_64-w64-mingw32.exe) and run it.

Discussion:
Under section 1, the link to the Windows binary is which gives a 404 error page. !
(The problem here is we now have both 32 and 64-bit installers, and thus the URL was split to reflect this. has the correct links, I guess the guide should either link to that page, or have both links.)
Change:
ItemType::Enum, ItemType::Constant, ItemType::Static, ItemType::Trait, ItemType::Function, ItemType::Typedef, ItemType::Union, ItemType::Impl, ItemType::TyMethod, ItemType::Method, ItemType::StructField, ItemType::Variant, <del> ItemType::AssocType, ItemType::AssocConst, ItemType::ForeignType] { </del> <ins> ItemType::AssocType, ItemType::AssocConst, ItemType::ForeignType, ItemType::Keyword] { </ins> if items.iter().any(|it| !it.is_stripped() && it.type_() == myty) { let (short, name) = item_ty_to_strs(&myty); sidebar.push_str(&format!("<li><a href="#{id}">{name}</a></li>",

Discussion:
As per : Add the following link () next to the existing ones: See all std's items Re-exports Primitive Types Modules Macros <-- this one. cc
Thanks for opening the issue! I'll send the PR tomorrow (but if you want to do it, please go ahead ).
Change:
} } <del> if !unnormalized_trait_sig.output().references_error() { debug_assert!( !collector.types.is_empty(), "expect >0 RPITITs in call to `collect_return_position_impl_trait_in_trait_tys`" </del> <ins> if !unnormalized_trait_sig.output().references_error() && collector.types.is_empty() { tcx.dcx().delayed_bug( "expect >0 RPITITs in call to `collect_return_position_impl_trait_in_trait_tys`", </ins> ); }

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at 'expect 0 RPITITs in call to '', 'thread 'rustc' panicked at 'expect 0 RPITITs in call to '' 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: [collectreturnpositionimpltraitintraittys] comparing an impl and trait method signature, inferring any hidden types in the process [typeof] computing type of [checkwellformed] checking that is well-formed [checkmodtype_wf] checking that types are well-formed in top-level module [analysis] running analysis passes on this crate --
Okay, lol, here the types obviously do unify and therefore isn't effective in this situation.
More fundamentally, the thing that goes “wrong” in these kinds of situations is the fact that we call if we have which is the case because generated one because the HIR (!) type visitor inside found an opaque type in the HIR type (here ) while the lowered type (here ) no longer contains any opaque types ultimately leading to the assert triggering. In short: visit the HIR ty , see an opaque type and take note of that synthesize an assoc ty for the RPITIT (I think) because of (1) lower the ty to due to the argument kind mismatch try to collect RPITITs on the lowered type & fail to find the opaque type I don't know if this is actually useful in general :thinking: What kinds of bugs is it supposed to catch?
cc
So either we delay the detection of RPITITs and the synthesis of RPITIT assoc tys until after HIR ty lowering / AstConv (but I don't know if that's an option) or we modify the assert (either remove it outright or check the corresp. HIR ty, I don't know if that makes sense; furthermore oli is/was on a roll to remove HIR operations from this part of the code base iirc).

Yeah, this assertion was simply there to make sure we weren't incorrectly calling for methods that had no RPITITs themselves (b/c it's expensive, and it actually is a bit stronger in what it enforces in the method signatures since it uses rather than in the signature relation for lifetime reasons), but now that this code isn't being changed much, I doubt that will ever happen. Feel free to remove it, or else I can do.
We could also delay a bug on mismatch
Change:
<ins> // run-pass #![allow(dead_code)] struct Foo { foo: i32, bar: (), baz: (), } fn use_foo(x: Foo) -> i32 { let Foo { foo, bar, .. } = x; //~ WARNING unused variable: `bar` //~| help: try removing the field return foo; } fn main() {} </ins>

Discussion:
I got this error message recently: will work, but just removing completely from the pattern would be better. E.g. the suggestion could be . The particular example was within rustc, but it should be very easy to replicate in a self-contained example. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Is this ? Where does this suggestion come from? Can I please get the path for it!
claim
It's been 3 months - are you still working on this? If not, I'd like to claim it instead.
There was no activity for a while, so I took a liberty of implementing this. claim
Change:
let lldiscr = C_integral(Type::from_integer(ccx, d), discr.0 as u64, true); let mut vals_with_discr = vec![lldiscr]; vals_with_discr.extend_from_slice(vals); <del> let mut contents = build_const_struct(ccx, &variant, &vals_with_discr[..]); let needed_padding = l.size(dl).bytes() - variant.min_size.bytes(); </del> <ins> let mut contents = build_const_struct(ccx, &variant, &vals_with_discr[..]); let needed_padding = l.size(dl).bytes() - variant.stride().bytes(); </ins> if needed_padding > 0 { contents.push(padding(ccx, needed_padding)); }

Discussion:
This code () gives me a segfault on the current beta: I've reduced it as much as I can, even removing the constructor on the enum causes it to work. I expect the output to be (which it is on stable), but instead I get
Appears to be broken on nightly as well - I get a stack overflow on x86_64 darwin.
FWIW, I don't get a segfault on beta or nightly with the playpen, I just get this output for both:
The stackoverflow on x86_64 darwin goes away for me on any .
This strongly reminds me of and .
Change:
for error in errors.iter() { match *error { ConcreteFailure(origin, sub, sup) => { <ins> debug!("processing ConcreteFailure") </ins> let trace = match origin { infer::Subtype(trace) => Some(trace), _ => None,

Discussion:
For the input file below, the two distinct invocations of (but with identical arguments) are non-deterministically deciding whether or not to prompt with the "consider using an explicit lifetime parameter" hint. Input file (): Transcript: (See also for a problem with the suggestion actually provided by when it chooses to actually provide one.)
I tested it a bit, and the issue seems to be is fed slightly different information each time. In the first case we have a and in the second . In the constraint graph for some node we are trying to infer, there are multiple incoming edges and outgoing edges to and from . From my understanding the compiler only picks one node from these incoming edges and one node from these outgoing edges, and it doesn't pick the same pair each time (what I don't understand is why I didn't see the and variations).
I'm getting a non-deterministic error message using the latest nightlies: It's non-deterministic on my Fedora 20 machine but not my OSX machine.
Change:
impl<'a, 'tcx> MatchCheckCtxt<'a, 'tcx> { pub fn create_and_enter<F, R>( tcx: TyCtxt<'a, 'tcx, 'tcx>, <ins> param_env: ty::ParamEnv<'tcx>, </ins> module: DefId, f: F) -> R where F: for<'b> FnOnce(MatchCheckCtxt<'b, 'tcx>) -> R

Discussion:
Attempting to pattern match a slice with a constant value and THEN a slice literal causes an ICE. Simple test case: However simply changing the order to test the slice literal and then the const slice compiles fine: Error message: rustc version:
So... I do have a fix for byte slices, but that just exposed that we have the same ICE for other slices: This can be fixed, too, but I need to wait for to be merged before being able to do this in a reasonable way.
Change:
obj)) } <ins> pub fn enter_type_of(&self, ty: Ty<'tcx>) -> TypeOfDepthLock<'b, 'tcx> { let current_depth = self.local.type_of_depth.get(); debug!("enter_type_of({:?}) at depth {:?}", ty, current_depth); if current_depth > self.sess().recursion_limit.get() { self.sess().fatal( &format!("overflow representing the type `{}`", ty)) } self.local.type_of_depth.set(current_depth + 1); TypeOfDepthLock(self.local) } </ins> pub fn check_overflow(&self) -> bool { self.shared.check_overflow }

Discussion:
Repeating segment:
Note: the type is regular, just not representable (actual non-regular data types make selection overflow, possibly at trans time).
This particular case could be handled in type-checking, but the general case requires some sort of recursion check after the type has been monomorphized.

causes a stack overflow.
This is a stack overflow inside middle::traits::project::normalizeprojectiontype

I've encountered a variant of this bug (or is it another bug? please advise if so and I will post it separately): If I remove the lifetime, the stack overflow no longer occurs.
Seems to be a dupe of
example was fixed in 1.4.

The following program generates a trans-time stack overflow.
Can confirm this is still an issue
This is somewhat distinct from , as it creates an irregular type without selection errors.
actually, not really.

On 3/4/2015 on playpen, the following code: the following error: This may be considered a duplicate of issue , which notes a similar problem with recursive trait bounds. I figured this may be unique given that this involves a recursive associated type on a trait, rather than a recursive trait itself.
cc
This was just rediscovered in the #rust IRC.
The code that that IRC example was simplified from was code that looked reasonably sane (and was quite far removed from simple recursion like this), so trying to come up with an error message instead of a crash would be quite handy.
Change:
~"index is not an integer-constant  expression") }; <del> let (arr, _len) = match ty::get(bt).sty { </del> <ins> let (arr, len) = match ty::get(bt).sty { </ins> ty::ty_evec(_, vstore) | ty::ty_estr(vstore) => match vstore { ty::vstore_fixed(u) =>

Discussion:
Currently the consts translation pass can only handle indexing into a slice if it represents an entire vec, not a sub-vec thereof. Since we don't (presently) have any syntax for making a sub-slice as a const expr, this isn't a big deal. Yet. But it might become one in the future. If so, we need to do a fair bit more work in the const translator, since it appears LLVM doesn't want to feed us back the number-values of consts that depend in any way on the size of a datum. Such as, say, a size bound. Awkward.