jiebi/CodeConvo huggingface dataset:
Change:
<ins> error: expected identifier, found `!` --> $DIR/issue-77993-2.rs:4:10 | LL |     macro!(); |          ^ expected identifier error: aborting due to previous error </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. --edit: I reduced some code of a different occurrence and came up with <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --I bisected the regression to / <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
Reduced code from another project that also triggers this ICE: `
Cargo-bisetc-rustc points to /
cc and
The error on stable is So it's a case of error-ICE.
After some trying I found out that this will panic for every keyword, that is followed by an unexpected token, in an async function, that returns
Assigning and removing as in the prioritization working group.
I can also reproduce the ICE with the following code:
After investigation, I think I have found the cause of the bug. When we get to the contained in is a , because of the invalid or or any wrong syntax. Then we call which expects a so it panics.
Unless someone gets to it before, but I can get a fix in by if not over the weekend. Though from what I understand about that code it shouldn't be TyKind::Error, it should be Infer/Tuple. interesting...
Potential fix in
A possible duplicate.
Fix in (in progress)
The third time's the charm. More future proof solution:
I was just about to open a new issue when I saw this and it looks like it has been fixed—but since I already typed it out and it might provide further info, here it is: <!-- 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. --or No ICE when: just the return value is omitted just the args are omitted both the return value and args are omitted is replaced with <!-- 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.

--: No ICE on <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I hit a similiar bug... As it is already known and fixed, I won't post a new bug report, but as I already have it, here is my data point: I don't have a minimal example, I just know that I got an error on the following git checkout: <!-- 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. --: The following command triggered the ICE: <details<summary<strongBacktrace</strong</summary<p</p</details
Change:
<ins> impl X { //~^ ERROR cannot find type fn getn<const N: usize>() -> [u8; N] { getn::<N>() } } fn getn<const N: cfg_attr>() -> [u8; N] {} //~^ ERROR expected type, found built-in attribute `cfg_attr` //~| ERROR mismatched types fn main() {} </ins>

Discussion:
<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. --<!-- 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
's parameter doesn't have to have an error type; it appears it can be any type (that doesn't trip the full feature gate error.) This version ICEs without any prior diagnostics: Neither version ICEs on beta or stable. (const generics aren't stable on 1.50, but after reporting an error for use of unstable features the compiler reports the same errors as beta and doesn't ICE.) label A-const-generics regression-from-stable-to-nightly
Bisected, this is a weird one:
I've attempted a second bisection using the snippet from the , I got a different result (not sure why, unsure if it helps) searched nightlies: from nightly-2021-02-15 to nightly-2021-03-18 regressed nightly: nightly-2021-03-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: </details
I guess that was a lie I'm looking into this
Assigning and removing as in the prioritization working group. label: +P-high -I-prioritize
Change:
tcx, trait_ref.substs.extend_to(tcx, assoc.def_id, |param, _| tcx.mk_param_from_def(param)), ); <ins> let fn_sig = tcx.liberate_late_bound_regions(fn_hir_id.expect_owner().to_def_id(), fn_sig); </ins> <del> let ty = if let Some(arg_idx) = arg_idx { fn_sig.input(arg_idx) } else { fn_sig.output() }; Some(tcx.liberate_late_bound_regions(fn_hir_id.expect_owner().to_def_id(), ty)) </del> <ins> Some(if let Some(arg_idx) = arg_idx { *fn_sig.inputs().get(arg_idx)? } else { fn_sig.output() }) </ins> } #[instrument(level = "trace", skip(self, generate_err))]

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
Minimal:
label +S-bug-has-mcve
Change:
)*) } <del> step_impl_unsigned!(usize u8 u16 u32); step_impl_signed!([isize: usize] [i8: u8] [i16: u16] [i32: u32]); </del> <ins> step_impl_unsigned!(usize u8 u16); #[cfg(not(target_pointer_witdth = "16"))] step_impl_unsigned!(u32); #[cfg(target_pointer_witdth = "16")] step_impl_no_between!(u32); step_impl_signed!([isize: usize] [i8: u8] [i16: u16]); #[cfg(not(target_pointer_witdth = "16"))] step_impl_signed!([i32: u32]); #[cfg(target_pointer_witdth = "16")] step_impl_no_between!(i32); </ins> #[cfg(target_pointer_width = "64")] step_impl_unsigned!(u64); #[cfg(target_pointer_width = "64")]

Discussion:
is implemented for Range<T. TrustedLen that the upper bound of is None if the iterator produces more than elements. to produce its result. The of subtracts the lower from the upper value and casts it to usize. This is for u32. On 16bit platforms, the result of the subtraction of two u32 values may not fit inside , producing an invalid . This means, that e.g. collecting into a Vec using its allows writing beyond its reserved buffer. One such example input would be . Reference: /cc
Change:
<ins> // Copyright 2016 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_macro)] #[macro_use] extern crate foo; #[derive(A)] struct A; fn main() { let _b = B; } </ins>

Discussion:
Noticed it causing issues with cargo as it uses and then parses the files as part of the fingerprinting process. It seems every instance of macro generated code (e.g. via serde_derive) creates a entry into this file which when cargo tries to look up it can't find. Cargo issue:
Added this to the macros 1.1 tracking issue (I consider this a blocker for stabilization)
Change:
color: #929292; } <del> .module-item .stab { </del> <ins> .module-item .stab, .import-item .stab { </ins> color: #000; }

Discussion:
See is unstable, however there is no unstable tag showing that, it would be nice if it would, just so it can be seen at a glance without going to their respective pages. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that rustdoc already does something similar for : ! It could use a similar format for re-exports.
Really could just copy the existing tags (see -asm) and put em after the path.
claim
Change:
<ins> error: constant evaluation is taking a long time --> $DIR/field-access-after-const-eval-fail-in-ty.rs:4:10 | LL |     [(); loop {}].field; |          ^^^^^^^ | = note: this lint makes sure the compiler doesn't get stuck due to infinite loops in const eval. If your compilation actually takes a long time, you can safely allow the lint. help: the constant being evaluated --> $DIR/field-access-after-const-eval-fail-in-ty.rs:4:10 | LL |     [(); loop {}].field; |          ^^^^^^^ = note: `#[deny(long_running_const_eval)]` on by default error: aborting due to 1 previous error </ins>

Discussion:
<!-- [31mICE[0m: Rustc '' 'thread 'rustc' panicked at ', 'thread 'rustc' panicked at ' 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: [livesymbolsandignoredderivedtraits] finding live symbols in crate [checkmod_deathness] checking deathness of variables in top-level module [analysis] running analysis passes on this crate --
Bisects to nightly-2023-06-02 commit[0] 2023-05-31: Auto merge of - oli-obk:valtrees2, r=lcnr commit[1] 2023-05-31: Auto merge of - petrochenkov:strictflavor, r=lqd,wesleywiser commit[2] 2023-06-01: Auto merge of - Urgau:upliftcastreftomut, r=b-naber commit[3] 2023-06-01: Auto merge of - oli-obk:constevalstep_limit, r=fee1-dead commit[4] 2023-06-01: Auto merge of - Dylan-DPC:rollup-93zj7jw, r=Dylan-DPC commit[5] 2023-06-01: Auto merge of - saethlin:enable-sroa, r=oli-obk,scottmcm commit[6] 2023-06-01: Auto merge of - cjgillot:separate-const-switch, r=oli-obk commit[7] 2023-06-01: Auto merge of - Kobzol:try-build-skip-docs, r=mark-simulacrum ERROR: no CI builds available between and within last 167 days
Minimized:
Very likely btw.
Change:
)+ } <del> impl Tool { /// Whether this tool requires LLVM to run pub fn uses_llvm_tools(&self) -> bool { match self { $(Tool::$name => false $(|| $llvm)*,)+ } } } </del> impl<'a> Builder<'a> { pub fn tool_exe(&self, tool: Tool) -> PathBuf { match tool {

Discussion:
See . Unfortunately the "fix" to that bug breaks the build when building using 1.31.0 and you have to unapply the patch to make it work against 1.31.0. e.g. from : ~ The problem here is that if stage0 is 1.31.0 then the patch MUST be unapplied, if stage0 is 1.32.0 then the patch MUST be applied. Obviously we can't do both at once. However in both Debian and Fedora we occasionally use either the current or the previous version of rustc to build a given version of rustc, and both of these versions should work. cc
Doing things this way (using stage2) would also have ensured that was detected early, and never made it into a release.
We would prefer to build tools such as compiletest with the bootstrap compiler because stage1, stage2 compilers take a long time to build. I think largely we just can't at this point support building with multiple compilers -- i.e., the bootstrap compiler should be the same one we use in tree. We just don't have the CI budget and resources to test and support multiple versions of the compiler for crates using unstable features. As such, I think the only resolution here will be to close this... cc and though since this is somewhat of a policy type decision (and we don't have a firm policy AFAIK).
As a matter of policy, we do need such rebuild-bootstrapping to continue to be supported to some extent, even if it's only a "tier-2" use case. That is, fixing these sort of issues reactively is still better than nothing.
Is conditional compilation based on the compiler version possible in Rust today? That could be an alternative solution, instead of always using stage2. The language is a bit technical and I couldn't figure it out.
I guess for now, I could hack that sort of logic into the Debian build script manually in an ad-hoc way - applying the patch vs not, based on the stage0 compiler version.

I think if we wanted to solve this issue the best way to do it would be to: Require compiles on stable, except for the dependency on the crate Have depend on std/test in-tree binaries, so we always build them (with the stage0 compiler) That way works with rebuild-bootstraping and normal use cases because it's not using anything unstable except libtest, which is built from source to link against and already solves this problem otherwise.
I think in general a policy of unstable tools/dependencies having the requirement of being in-tree deps instead of beta is reasonable, yeah. I can try to make a patch that makes compiletest (and if there are any other such tools) do this sometime this week.
Same issue with 1.40.0 again, when using itself as stage0: ~ CC AFAICT you do not have a patch that fixes this on Fedora either.
For 1.40.0 the relevant commit to conditionally-apply or not is . For the upcoming 1.41.0 (or is it 1.42.0) stable release it seems we will have to do the same thing for .
Change:
//~| ERROR `T` does not live long enough //~| ERROR `T` does not live long enough //~| ERROR `T` does not live long enough <ins> //~| ERROR `T` may not live long enough </ins> // // FIXME: This error is bogus, but it arises because we try to validate // that `<() as Foo<T>>::Type<'a>` is valid, which requires proving

Discussion:
This code compiles after although it shouldn't: () This is similar to in that we're not taking into account placeholder regions when "promoting" type-tests from the closure to its caller: label T-types regression-from-stable-to-beta C-bug A-NLL I-unsound <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I guess it would be an easy fix claim
The unsoundness exploitation in can easily be adapted for this issue, so it is in fact a soundness issue:
issue touched in today's T-compiler meeting, . Will also be discussed tomorrow during the T-types meeting.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Change:
impl Iterator<Path> for Directories { fn next(&mut self) -> Option<Path> { <del> match self.stack.shift() { </del> <ins> match self.stack.pop() { </ins> Some(path) => { if path.is_dir() { match readdir(&path) {

Discussion:
It calls on a vector repeatedly. Example: and are directories with that many files in them. Theoretically this wants a deque.
Would keeping an index be sufficient? Just return and bump each time. It seems to me we don't need any fancy data structure. I can work on this.
That might work, but it does mean that the size of the internal vector grows to be the total number of elements ever touched, rather than just the number of children of recently-walked directories. It would also require cloning each of them. (Maybe not, if it stored internally and returned ...)
What about this. When we run out of space at the end, check if we are using more than half of the vector. If we are, allocate a new one at least twice as large. If we are not, swap all the values to the beginning of the vector. This way we have amortized linear time without needing to use a full blown deque. On Apr 10, 2014 2:14 AM, "Huon Wilson" wrote:
If you can get that to work, I guess so. But really, it would be better/more correct to just use a proper ... if std had access to one.
I am going to guess that taking out of std is undesirable. I can't really think of another way to do this rather than creating a simple . I'll work on it if you think this is acceptable.
"It calls .shift on a vector repeatedly." but it's very slow. Vec/Str need an efficient way to shift() multi-items
This isn't multiple items, it needs to shift the s off one at a time.
( I would be OK with moving deque into a "secret" module inside std and reexporting it from libcollections, however rustdoc doesn't support this nicely just yet.)
How about something along these lines: I didn't test the above, removing syntax errors is left as an exercise to the reader. Edit: Never mind, I see this changes the order that walk_dir guarantees. I'll try and rewrite my proposal tonight to make it emulate the current behaviour.
I'm not sure the current order is important, I don't know though (if it's not important we can probably just use as a stack, which is efficient).

However, if we wish to retain the current order, I really do think the correct solution is to just use a deque, rather than write a complicated specialised data structure for this relatively simple task. (Unless that data structure has other significant benefits, of course. Maybe avoiding the copies from each vec to main deque will be noticably more efficient?)
Change:
use arena::TypedArena; <del> use std::cmp::Ordering; </del> <ins> use std::cmp::{self, Ordering}; </ins> use std::fmt; use std::iter::{FromIterator, IntoIterator, repeat};

Discussion:
Hello, According to this , I have writted this example: But after the rustc 1.14.0-nightly version from 2016-10-25 --, I expected to see this happen:
Minimal example Fails with
regression introduced in .
How can this be a stable-nightly regression when this affects a gated feature?
Not sure what's the policy about it. It's a regression.
Yeah, I totally agree that this is a regression, although the label is inaccurate. I have wanted a label in the past (for eg. ), and think that once upon a time there even was such a label.
Change:
/// Test if it is valid for a MIR assignment to assign `src`-typed place to `dest`-typed value. /// This test should be symmetric, as it is primarily about layout compatibility. pub(super) fn mir_assign_valid_types<'tcx>( <ins> tcx: TyCtxt<'tcx>, </ins> src: TyAndLayout<'tcx>, dest: TyAndLayout<'tcx>, ) -> bool {

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:
<ins> error[E0792]: expected generic lifetime parameter, found `'_` --> $DIR/under-binder.rs:6:5 | LL | type Opaque<'a> = impl Sized + 'a; |             -- this generic parameter must be used with a generic lifetime parameter ... LL |     f |     ^ error: aborting due to previous error For more information about this error, try `rustc --explain E0792`. </ins>

Discussion:
Found this while minimizing :smile: So maybe related? didn't seem like duplicates. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details label +S-bug-has-mcve +F-typealiasimpl_trait
Regression in nightly-2022-07-01 reproduced based of a modifiction of which does not need any feature gates and crashes stable:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
_ => signal!(e, NonConstPath), }, Some(ast_map::NodeTraitItem(..)) => signal!(e, NonConstPath), <del> Some(_) => unimplemented!(), </del> <ins> Some(_) => signal!(e, UnimplementedConstVal("calling struct, tuple or variant")), </ins> } }

Discussion:
at the current version of error: internal compiler error: unexpected panic note: the compiler unexpectedly panicked. this is a bug. note: we would appreciate a bug report: note: run with for a backtrace thread 'rustc' panicked at 'internal error: entered unreachable code', playpen: application terminated with error code 101
The reason this is happening is because the code thinks is an enum variant or a tuple struct. The code around this is somewhat redundant and would probably better be solved by making enum variants const evaluable and adding a function that translates s to

This code wrongly states "expected constant integer for repeat count, but non-constant path in constant expression" This one works
accidentally fixed in
Change:
// It already exists Some(ref child) if child.get_module_if_available() .is_some() && <del> child.get_module().kind.get() == ImplModuleKind => { </del> <ins> (child.get_module().kind.get() == ImplModuleKind || child.get_module().kind.get() == TraitModuleKind) => { </ins> ModuleReducedGraphParent(child.get_module()) } Some(ref child) if child.get_module_if_available()

Discussion:
This code: generates this error: I couldn't find any existing issue on this, but this is expected to work, right?
cc
Was this in an RFC?
DST was pre-RFC (the design anyway), so no, it was not.
It as a good question whether this is supposed to work or not. Since traits are types now, just unsized, I would say "yes". But since an impl for a trait is no different to just providing default methods, perhaps we want to avoid that overlap. Shouldn't be hard to fix if we all agree on "yes", but cc to check he agrees.
As I understand it, an for a trait would be quite different than providing default methods: Even when a trait object is formed, there's no dynamic dispatch (vtable entries) for these methods. The methods cannot be overridden in an . The methods may also exist on the trait, in which case (according to our dispatch rules) the inherent versions would take precedence. I think the closer correspondence is to creating an extension trait with a blanket -- and given that inherent s are in some sense supposed to be equivalent to "anonymous", always-in-scope extension traits, I think that makes sense. My guess is that this was an intended, but implicit part of the DST proposal, but can speak more directly to that.
These subtle differences make me want it less. But the blanket impl-like use case seems legitimate. I agree with the intended but implicit assessment - I vaguely remember this coming up as a use case at some point
I've always assumed this would work but I'm curious was there a specific point in the libraries that required it?
IIRC this came out of playing around with the method definitions, which are currently all provided by extension traits. Not a huge deal if we can't do this for 1.0.
I started looking at this, but the hard bits seem to be some adjustment to method selection, so I'll wait on landing before doing this
I think there is some serious utility in providing this, especially for things like Any. I will try to dig up some other use-cases. Note that since is currently marked adding this later would mean deprecations etc.
Change:
_ => { /* mark as unpromotable below */ } } } else if let TempState::Defined { ref mut uses, .. } = *temp { <del> match context { LvalueContext::Borrow {..} | LvalueContext::Consume | LvalueContext::Inspect => { *uses += 1; return; } _ => { /* mark as unpromotable below */ } </del> <ins> // We always allow borrows, even mutable ones, as we need // to promote mutable borrows of some ZSTs e.g. `&mut []`. let allowed_use = match context { LvalueContext::Borrow {..} => true, _ => context.is_nonmutating_use() }; if allowed_use { *uses += 1; return; </ins> } <ins> /* mark as unpromotable below */ </ins> } *temp = TempState::Unpromotable; }

Discussion:
This code produces a compiler error with but compiles successfully with : The error is:
cc
This has to do with how the result of a checked op is a tuple and the 2's complement wrapping value is accessed through : the fix would be to track an initialization with a checked op in a field of , then treat as constant if is promotable and has that flag. I believe that the promoter will work as-is, it's just the constant qualifier that needs to understand this.
Looking at it again, the const qualifier works fine with fields, but the promoter's initial set of potentially promotable temporaries doesn't include the tuple because one of the uses is by-field.