jiebi/CodeConvo huggingface dataset:
Change:
vtable_base += COMMON_VTABLE_ENTRIES.len(); } VtblSegment::TraitOwnEntries { trait_ref, emit_vptr } => { <del> if trait_ref == trait_to_be_found { </del> <ins> if tcx.erase_regions(trait_ref) == trait_to_be_found_erased { </ins> return ControlFlow::Break(vtable_base); } vtable_base += util::count_own_vtable_entries(tcx, trait_ref);

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. --: This is also present in beta and nightly versions, but it is not present on 1.55.0 stable. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
56.0 is released on stable, and it ICEs there as well. label regression-from-stable-to-stable
Bisection led to nightly-2021-07-26. Automatic commit bisection failed. Manual commit bisection: Regression comes from .
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
Oops. Sorry for creating this ICE. I haven't really dig into this issue yet, but from the description, it seems this ICE comes from where the equality should be within a certain call, but didn't because of the HRTB region. This inequality is because the two parameters comes from two different routes. The first comes from iterator, which is called from The second comes from generator, which lived in , i think the call is the real difference here. This is my current theory, and i'll try to validate it with debugging rustc this week. I'm not totally sure what's the best way to fix this. I think maybe could give me some advice dealing with HRTBs here?
By the way, i've printed out the contents of the vtable for :
Should it just use ? Or I guess it needs the too... Hmm, probably since this is around codegen, we need to erase regions in both trait refs. But, I'd like to see what the two trait refs are.
is and is So... They're the same with , but inequal? I'm a little confused... So i switched to use , and they're a little different: is and is Complete diagnostics output:
This could "just" be fixed by anonymizing both trait refs.

The here is not the same as here . I have to remember how we deduplicate these predicates elsewhere.
Created for erasing regions before comparison. Let me know if there's a more proper approach, and i'll update the pr accordingly.
Anyone think this needs a backport?
Change:
<del> error[E0391]: cycle detected when computing layout of `Foo<()>` | = note: ...which requires computing layout of `<() as A>::Assoc`... = note: ...which again requires computing layout of `Foo<()>`, completing the cycle note: cycle used when elaborating drops for `main` --> $DIR/recursive-type-2.rs:11:1 | LL | fn main() { | ^^^^^^^^^ = note: see https://rustc-dev-guide.rust-lang.org/overview.html#queries and https://rustc-dev-guide.rust-lang.org/query.html for more information error: aborting due to 1 previous error For more information about this error, try `rustc --explain E0391`. </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. -- <!-- 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</detailsThis regressed in , previously it output a cycle error: label -I-ICE +I-crash +regression-from-stable-to-nightly
Bisection points to , but I don't have the context to determine which PR it was, maybe Assigning P-medium as this was already non-working code, and just the error message is a bit terse. label -I-prioritize +P-medium
Change:
} all_pointer_widths.insert(format!("{}bit", cfg.pointer_width)); <del> if target == config.target { current = Some(cfg); } </del> all_targets.insert(target.into()); } Self { <del> current: current.expect("current target not found"), </del> <ins> current: Self::get_current_target_config(config), </ins> all_targets, all_archs, all_oses,

Discussion:
Prior to , compiletest would take into account when determining whether a test target can unwind. It did so by calling , which changes the reported panic strategy depending on the flags: After the PR, compiletest calls which always reports the default panic strategy for the target (even if are passed): This causes a problem for us because we run the compiler test suite against a toolchain built with . Compiletest will run tests marked with even though they panic (and thus fail). I see a few options for fixing this issue: Have respect any additional flags passed. Parse specifically for and modify the return value of to take it into account. Add some new configuration flags to compiletest to control panic strategy for the selected target. cc who authored the original PR
This seems like the best solution to me.
WG-prioritization assigning priority (). label -I-prioritize +P-high
Agree with jyn here on the solution. Unfortunately I won't have much time myself in the coming weeks to address this :(
Change:
fn use_color(opts: &TestOpts) -> bool { match opts.color { <del> AutoColor => get_concurrency() == 1 && stdout_isatty(), </del> <ins> AutoColor => !opts.nocapture && stdout_isatty(), </ins> AlwaysColor => true, NeverColor => false, }

Discussion:
The control characters seem to cause strange artifacts so colors are disabled.
I don't think is correct, for reasons I left on the commit.
We could just hunt down all the tests that log to error or print to stdout and make them log to debug instead, then call it a day. Seeing the pretty colors is super nice. Probably should still be reverted though, unless there's something about it I'm missing.
Sorry. I'll revert the commits.
Added far-future milestone
Bug triage. Far-future still seems right.
Triage bump. There's been no change.
Triage bump. Still relevant.
I believe the test runner captures stdio now. It should be safe to print colors carefully.
Change:
.arg("--image-dir") .arg(&this.image_dir) .arg(format!("--component-name={}", &component_name)); <ins> if let Some((dir, dirs)) = this.bulk_dirs.split_first() { let mut arg = dir.as_os_str().to_os_string(); for dir in dirs { arg.push(","); arg.push(dir); } cmd.arg("--bulk-dirs").arg(&arg); } </ins> this.non_bare_args(cmd); }) }

Discussion:
CC On today's git () seems to get stuck if you are building docs. In : will get stuck at: The underlying command is: Adding this to the config seems to work around the hang: Thanks!
How long did you let the command run before killing it? I remember installing the docs taking a long time last time I did it.
I left it for half an hour or so IIRC. I'll run it for longer and see if it goes away. How long do you think it should take to install on a modern SSD?
I don't remember exactly how long it takes, but it doesn't depend on the speed of the disk. is just really inefficient. You can see if it's actually hanging by checking the contents of this command while it's installing:
The log file is empty, but I can see new files appearing on the disk (using and ) so progress must be occurring. Slowly.
It's been about 40 minutes now. It seems to be adding files to is that right?
So it's just very slow.
I took a look into this. The main issue is that the generated is very inefficient; it takes about 5 minutes to copy 2500 files (there are more than 2500, but I got bored and cancelled it). what do you think about rewriting this inner loop in Rust so it's not launching so many external processes?
This issue is compounded on macOS, where it seems to be even more inefficient to launch lots of processes from a shell. Sorry I don't have timings, but it takes tens of minutes at least for this step [edit: over an hour]; long enough that I would expect most users who are trying to build our software from source in macOS (it's Zcash, which installs a pinned version of Rust in order to build) are likely to think it's hanging and give up.
I think the problem may largely be that the generated for rust-docs component (at least) is a file: list instead of using the directory: command; directory commands should be much more efficient. This change may be a recent(ish) regression; I suspect that fixing that is likely the right solution here.
Oops I forgot to link back here: we discussed this briefly and it was difficult to do in a cross-platform way.
We solved our problem for Zcash by just not installing rust-docs (passing to ).

This reduced our total build time on macOS ! Obviously it doesn't solve the underlying issue.
FYI, addresses this (not the underlying cause of the inefficiency but the majority of its extent).
I bisected the underlying issue to “bootstrap: convert rust-docs to use Tarball” (). Before this commit, rust-docs installs in half a second, and is 1 line: After this commit, rust-docs installs in some twenty minutes, and is lines:
Proposed fix in . (We should also do the optimization in rust-lang/rust-installer of course.)
Change:
}), } } <del> // promoteds may never be mutated Place::Promoted(_) => bug!("encountered mutable promoted"), </del> <ins> // The rules for promotion are made by `qualify_consts`, there wouldn't even be a // `Place::Promoted` if the promotion weren't 100% legal. So we just forward this Place::Promoted(_) => Ok(RootPlace { place, is_local_mutation_allowed, }), </ins> Place::Static(ref static_) => { if self.tcx.is_static(static_.def_id) != Some(hir::Mutability::MutMutable) { Err(place)

Discussion:
Error: This only happens after cc The code that triggered this is .
cc seems like we need to report an error instead of panicking as originally written
Oh it's probably because we do promote
created a fix in , but I have no minimal repro and no time today
To clarify: you're making this an error? I don't see why we can't allow to be promoted.
good point
This ICE is currently causing errors in the , and crates in
I have tried building and it does not reproduce the issue for me on master or nightly :confused: trying a stage2 build now still can't repro on regex, but can repro on OPs file now.
ok, fix exists now
It looks like we've fixed the ICE here but there's still a change in behavior here, as well as a faulty diagnostic; this is while compiling cargo-registry from (at least the version in rustc-perf).
Change:
// when the unstable no_rc feature is turned on. // See https://github.com/rust-lang/rust/pull/84266 <del> use run_make_support::rustc; </del> <ins> use run_make_support::{rustc, source_root}; </ins> fn main() { rustc() .edition("2021") .arg("-Dwarnings") .crate_type("rlib") <del> .input("../../../library/alloc/src/lib.rs") </del> <ins> .input(source_root().join("library/alloc/src/lib.rs")) </ins> .cfg("no_rc") .run(); }

Discussion:
Some run-make tests refer to stdlib sources with which seems not ideal. suggested that we should introduce a helper to make this less fragile.
There is already the env var set by compiletest for the source root.
I'm actually dumb, we even already have in the support library:
That's a very descriptive environment variable name, lol
Change:
static A: u8; //~ ERROR free static item without body static B; //~ ERROR free static item without body <ins> //~^ ERROR missing type for `static` item </ins> static mut C: u8; //~ ERROR free static item without body static mut D; //~ ERROR free static item without body <ins> //~^ ERROR missing type for `static mut` item </ins>

Discussion:
Reproducible with stable and nightly compilers. : : Maybe this is a duplicated of but I'm not sure as the example there is more complex. : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Regressed in 1.52.0. The error in 1.51.0 wasn't so great either though, but at least it didn't ICE:
Regression in nightly-2021-03-08 (too long ago to get build artifacts per commit). That's the commit range .... Possibly related to an interaction between (which seems to have landed in that commit range) and dtorck?
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Change:
KeyMustBeAString, ExpectedColon, TrailingCharacters, <ins> TrailingComma, </ins> InvalidEscape, InvalidUnicodeCodePoint, LoneLeadingSurrogateInHexEscape,

Discussion:
Gives me:
That's because JSON doesn't allow for a trailing comma, I'd imagine.
The specification is clearly wrong here and the decoder should accept trailing commas.
Well, that's not how standards work.
Not sure what you mean by that. I'm not saying that the encoder should produce trailing commas.
There is some precedence for not allowing trailing commas: Go, Chromium, and Firefox reject such json. The specification is still wrong for not allowing them and I see no reason not to parse them.
sad but true. Please feel free to close the issue then.
We could, however, have a better error message.
It shouldn't fail, since it returns a containing possible parse errors.
Change:
<ins> error[E0308]: mismatched types --> $DIR/issue-82446.rs:11:9 | LL |         val |         ^^^ expected struct `Box`, found reference | = note: expected struct `Box<(dyn MyTrait + 'static)>` found reference `&Box<(dyn MyTrait + 'static)>` error: aborting due to previous error For more information about this error, try `rustc --explain E0308`. </ins>

Discussion:
The following code: produces the following error: is a , so writing would produce a . This is very unlikely to be what the user wants - and in this case, it won't even work, since there are no impls for . Tested on <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This problem occurs not only when 's type is , but also i32 and other types. This help message will be emitted if could coerce to . But I think this is weird. This coercion should be based on , and to coerce, we need implementation of for 's type. In other words, it seems that all types have implementation of . This behavior should be incorrect also from . I'm going to check why the compiler provides above implementation.
This suggestion uses to determine whether to emit the message. And then calls . execute trait selection. Even if a type needs implementation, trait selection does not check , . However, also . As a result, does not check whether 's type has implementation of . But, I have no idea how to fix this. I'll leave this issue.
Change:
fn parse_ty_bare_fn( &mut self, lo: Span, <del> params: Vec<GenericParam>, </del> <ins> mut params: Vec<GenericParam>, param_insertion_point: Option<Span>, </ins> recover_return_sign: RecoverReturnSign, ) -> PResult<'a, TyKind> { let inherited_vis = rustc_ast::Visibility {

Discussion:
Newcomers might attempt to write a “generic” function pointer like . In such case, the compiler should provide a better error message. Inspired by a recent Reddit thread I sadly cannot find anymore. Given the following code: The compiler should mention that function pointers may not be generic or […] may not have generic parameters, suggest to move the lifetime(s) to a parameter list (this should be machine-applicable in my judgement) and be able to recover: For later reference, the current output is: Given the following code: The compiler should mention that function pointers may not be generic or […] may not have generic parameters and be able to recover emitting two diagnostics, one for each line. The compiler could also suggest moving the generic parameter list further up to the owning function, struct, etc. if available. Note that this might not be what the user intended (since there is a semantic difference between hypothetical higher-ranked generics and normal ones) and therefore shouldn't be machine-applicable. For later reference, the current output is: label A-parser A-suggestion-diagnostics D-newcomer-roadblock <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
| LL | #[derive(my_macro_attr)] |          ^^^^^^^^^^^^^ not a derive macro <ins> | help: remove from the surrounding `derive()` --> $DIR/macro-namespace-reserved-2.rs:53:10 | LL | #[derive(my_macro_attr)] |          ^^^^^^^^^^^^^ = help: add as non-Derive macro `#[my_macro_attr]` </ins> error: can't use a procedural macro from the same crate that defines it --> $DIR/macro-namespace-reserved-2.rs:56:10

Discussion:
(The actual desired output should have colours and minuses on the removed derive, but to give the idea) Many users are not familiar with the terminology being used by the compiler error (i.e. the different flavours of procedural macro, derive vs attribute) and might be confused as to what they need to do in order to fix the error. Since the fix is straight-forward (i.e. remove the ), the compiler should show a code snippet that fixes the issue. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I have a partially functional implementation of this, though I've run into a bit of trouble, some guidance would be appreciated. Currently I'm implementing this next to the existing error in in . My trouble comes with knowing what the macro is invoked on, (function, struct), and sending the help message selectively based on that. Is there a way to get this information in , or is my approach wrong and the error should be elsewhere? As far as I can tell I am trying to implement this in a place before the AST is fully parsed, so this may be unviable
Change:
/// ``` #[stable(feature = "rust1", since = "1.0.0")] #[macro_export] <del> macro_rules! concat { ($($e:expr),*) => ({ /* compiler built-in */ }) } </del> <ins> macro_rules! concat { ($($e:expr),*) => ({ /* compiler built-in */ }); ($($e:expr,)*) => ({ /* compiler built-in */ }); } </ins> /// A macro which expands to the line number on which it was invoked. ///

Discussion:
Example: The macro is when in reality, the following call is legal (): I believe this is because . and (edit: also ) are in a similar boat (they also support trailing commas in places where the documented pattern suggests they would not). In all fairness this is not a big deal, and even has the conceivable benefit that the documentation is cleaner without such laser precision. I just thought it was worth making an issue for.
it's all good! These should be correct. Happy to take PRs.
closing since fix was merged
Change:
/// Basic usage: /// /// ``` <del> /// #![feature(unsigned_abs)] </del> #[doc = concat!("assert_eq!(100", stringify!($SelfT), ".unsigned_abs(), 100", stringify!($UnsignedT), ");")] #[doc = concat!("assert_eq!((-100", stringify!($SelfT), ").unsigned_abs(), 100", stringify!($UnsignedT), ");")] /// assert_eq!((-128i8).unsigned_abs(), 128u8); /// ``` <del> #[unstable(feature = "unsigned_abs", issue = "74913")] </del> <ins> #[stable(feature = "unsigned_abs", since = "1.51.0")] #[rustc_const_stable(feature = "unsigned_abs", since = "1.51.0")] </ins> #[inline] pub const fn unsigned_abs(self) -> $UnsignedT { self.wrapping_abs() as $UnsignedT

Discussion:
<!-- Thank you for creating a tracking issue! Tracking issues are for tracking a feature from implementation to stabilisation. Make sure to include the relevant RFC for the feature if it has one. Otherwise provide a short summary of the feature and link any relevant PRs or issues, and remove any sections that are not relevant to the feature. Remember to add team labels to the tracking issue. For a language team feature, this would e.g., be . Such a feature should also be labeled with e.g., . This label is used to associate issues (e.g., bugs and design questions) to the feature. --This is a tracking issue for on signed integral types. The feature gate for the issue is . Tracking issues are used to record the overall progress of implementation. They are also uses as hubs connecting to other relevant issues, e.g., bugs or open design questions. A tracking issue is however not meant for large scale discussion, questions, or bug reports about a feature. Instead, open a dedicated issue for the specific matter and add the relevant feature gate label. <!-- Include each step required to complete the feature. Typically this is a PR implementing a feature, followed by a PR that stabilises the feature. However for larger features an implementation could be broken up into multiple PRs. --- [ ] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- First implemented in <!-- Include a list of all the PRs that were involved in implementing the feature. --
Are there any outstanding issues with this feature gate? It has a trivial implementation that is unquestionably correct, and it seemed quite clear in the RFC that it was desired.
One significant issue I see is currently the implementation for returns instead of . Edit: I found the reason. The is instead of as . This was not a problem so far because didn't appear in any function signature until now. So changing the call site for all pointer sizes should be enough.
Hmm…the behavior for different widths (16, 32, or 64). However, usize and u16/32/64 are not the same type. I'll make a modification locally and open a PR shortly.
Yes, exactly. Good job with the PR!
Why of returns instead of ? IMHO, it is not valid.
This is fixed on nightly (that you need anyway to use this for now)
Nice, thank you!
Change:
self.expr(span, ast::ExprKind::Field(expr, field)) } <ins> pub fn expr_macro_call(&self, span: Span, call: P<ast::MacCall>) -> P<ast::Expr> { self.expr(span, ast::ExprKind::MacCall(call)) } </ins> pub fn expr_binary( &self, sp: Span,

Discussion:
In chrono we have support for behind a feature flag. As a workaround for I the line: It now gives a new error: cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The derived implementation for an enum is using . Manually implementing and using is a workaround.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
cc
I'm actually not sure this is a T-libs issue. I suspect it's related to , but I haven't had a chance to look into it yet.
I have confirmed this is an issue with the expansion of on s and aim to have a PR up tonight. As is a built-in macro, it is technically in T-compiler land, I believe. claim
PR is up, including a regression test: