jiebi/CodeConvo huggingface dataset:
Change:
<ins> #![feature(type_alias_impl_trait)] trait Allocator { type Buffer; } struct DefaultAllocator; impl<T> Allocator for DefaultAllocator { //~^ ERROR: the type parameter `T` is not constrained type Buffer = (); } type A = impl Fn(<DefaultAllocator as Allocator>::Buffer); fn foo() -> A { |_| () } fn main() {} </ins>

Discussion:
This produces an ICE (): It points to this assert firing: This assert assumes that if we match on a with a const, then must be . I'm not sure where this assumption comes from (I'd guess byte-array patterns), but it's clearly wrong. Note that this also fails with any other non- type here instead of . Note that this does not fail when the arrays are not behind references, or if we use slices instead of arrays. EDIT: removed unnecessary feature gate
The feature gate isn't needed to trigger the ICE
Oh, well spotted. And it appears that fails on stable too then
cc as it's possible this is related to your structural match work I guess?
Funny enough: this doesn't ICE but instead shows the correct "unreachable" warning
Reduced:
What the heck?!?
triage: P-high. Removing nomination. Self-assigning.
That's a leftover from matching on byte strings, which used to be one of the few constants one could actually match on.
I think it's one more of theses cases where we don't know how to handle properly. shouldn't even exist: specialization should be able to specialize consts by unpacking a pattern into its subpatterns, like we specialize everything else.
I've figured out a way to eliminate the ICE, but I do not think my code has the desired semantics. That is, I would imagine we would want this to be accepted: but my current draft code rejects the above as non-exhaustive. On the other hand, that does match the current behavior of the compiler, for better or for worse. Update: Or maybe I've forgotten the desirata for how match usefulness and consts are supposed to interact...?
This was not a stable reduction; on the current nightly, the above length-zero ZST array is accepted with no ICE, while the original length-one ZST array still causes an ICE.
Yet another fun variation on the test: yields:
The reason it exists is that we don't want to unpack a multi megabyte byte string you may have gotten from . That would be super inefficient and likely just cause an out of memory abort. The reason why I believe we should also do this optimization for other types is that you can easily transmute a multi megabyte byte string to another array type in a constant, and then you have the same problem all over again.

(Or you init with a repeat expression). I agree that it would be nicer and less fragilr if we just unpacked everything.
Btw, addresses a few of the ICEs around this
Since the original and reduced versions no longer ICE, but still does
The above no longer ICEs after , could do with a test
Change:
<ins> error[E0758]: unterminated block comment --> $DIR/unterminated-nested-comment.rs:1:1 | LL |   /* |   ^- |   | |  _unterminated block comment | | LL | | /* */ LL | | /* | | -- | | | | | ...as last nested comment starts here, maybe you want to close this instead? LL | | */ | |_--^ |   | |   ...and last nested comment terminates here. error: aborting due to previous error For more information about this error, try `rustc --explain E0758`. </ins>

Discussion:
Given: The compiler says: This initially confused me quite a bit because I couldn't figure out why Rust wasn't seeing block comment terminator. Eventually, I realized that the line changed from being a commented out line, to starting a nested block comment. Since block comments nest in Rust, I'm used to commenting out blocks without worrying about what's inside of them which made this behaviour surprising. I'm not sure how practical it is, but it would be cool if we could check for comments like in block comments to suggest them as the source of the problem. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
claim
Change:
Append = 5, AppendUnique = 6, Max = 7, <ins> Min = 8, </ins> } // Consts for the LLVM CallConv type, pre-cast to usize.

Discussion:
Enabling on rustc (nightly-2022-08-14) doesn't generate staticlibraries or cdylib anymore. This happens after the LLVM 14 to LLVM 15 change as bisected below where LLVM-15 sets the flag only for the module being compiled. Even with this build fails as there is a module without a name that doesn't have set. Earlier in BTI works even without requiring the The way I'm reproducing this (patch attached to make this easier) is by: in : This issue persists even in the latest build <details<summary<strongBacktrace</strong</summary<p</p</details are folders generated in the and folders searched nightlies: from nightly-2022-08-12 to nightly-2022-08-14 regressed nightly: nightly-2022-08-13 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details
Error: Label P-high can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Looks like commit is the start of this bug. Bug not reproduced by running: Other commits reverted for conflict reasons. On the project branch Commit base:
This bug only happens for release mode builds with the same which leads me to believe this unnamed module is release mode specific or this occurs due to some llvm-ir merging/optimization that doesn't happen for debug builds.
Change:
use std::usize; use syntax::ast; use syntax::print::pprust::PrintState; <ins> use rustc_data_structures::graph::OUTGOING; </ins> use util::nodemap::NodeMap; use hir; use hir::intravisit::{self, IdRange};

Discussion:
See . Here is a chart giving time output from with of the lines of the form uncommented. n -------- With this gist I've tried to create a fairly minimal example. It's not as minimal as maybe it could be because it's a little tricky to figure out what's causing the slow compiles and I've spent as much time as I can on this right now. It's very sensitive to seemingly irrelevant changes in the code. If I remove the unused variable, compile times dramatically improve. If I remove the empty loop, compile times dramatically improve. On my actual project, I am getting compile times in excess of 20 minutes. To compile a few thousand lines of code.
cc
Umm this is not an expansion problem but rather a borrowck problem - dataflow somehow takes O(n) iterations to converge.
Change:
// empty. } <ins> unsafe impl Send for .. { } </ins> impl<T> !Send for *const T { } impl<T> !Send for *mut T { } impl !Send for Managed { }

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:
color: var(--stab-code-color); } <del> .stab .emoji { </del> <ins> .stab .emoji, .item-info .stab::before { </ins> font-size: 1.25rem; <ins> } .stab .emoji { </ins> margin-right: 0.3rem; } <ins> .item-info .stab::before { /* ensure badges with emoji and without it have same height */ content: "0"; width: 0; display: inline-block; color: transparent; } </ins> /* Black one-pixel outline around emoji shapes */ .emoji { text-shadow: 1px 0 0 black, -1px 0 0 black, <del> 0  1px 0 black, </del> <ins> 0 1px 0 black, </ins> 0 -1px 0 black; }

Discussion:
! by
I'll try to change the display because it's really not great.
I wonder whether the formatting is the issue rather than the algorithm used to discover the required features. The formatting goes awry in the example above due to the large number of (redundant) features: That's technically correct, but not entirely helpful to a developer either. ' has the following entries in its table: To use , the only feature a client needs to enable is . The remaining features are automatically enabled recursively via the It would seem reasonable to prune the feature list by eliminating those features that are implicitly enabled. Doing this solves two issues: It makes the formatting a non-issue (here). It declutters the documentation, showing only information that clients can act upon. I'm not aware of a way to cancel automatic enablement of dependent features, so dropping this information from the documentation should be inconsequential in practice. If the formatting is being reworked nonetheless, here's what I'd like to see: Enclose the feature names in ASCII double quotes () for convenient copy-pasting. The crate to prevent them from being converted to smart quotes. Make the list comma-separated (again, for convenient copy-pasting). I understand that (as used currently) carries semantic information that needs to be reflected elsewhere. If is being used, it can remain as-is. We commonly don't need to copy-paste disjunct features.
Change:
/// # Examples /// /// ``` <del> /// #![feature(copied)] /// </del> /// let mut x = 12; /// let opt_x = Some(&mut x); /// assert_eq!(opt_x, Some(&mut 12)); /// let copied = opt_x.copied(); /// assert_eq!(copied, Some(12)); /// ``` <del> #[unstable(feature = "copied", issue = "57126")] </del> <ins> #[stable(feature = "copied", since = "1.35.0")] </ins> pub fn copied(self) -> Option<T> { self.map(|&mut t| t) }

Discussion:
This is a tracking issue for . Added in . Feature gate: . Related feature: in .
Did you mean in the first sentence?
Fixed.
The lint in Clippy should be updated to suggest this instead when the type is copiable.
So we a newtype because that's what we usually do. However, in this case, we could simply reuse and implement copied as: Are there notable reasons not to do this that I'm missing? Doing so would substantially decrease the cost of this feature for the standard library.
type wouldn't have the guarantees that does, as it calls the method, which can have side-effects (it shouldn't, but it's not something we can depend on). Although I suppose we currently DO expose specialization in structure when implementation is incompatible with implementation. This seems like a bug, so I will fix that in a separate PR.
See .
The comment about the type belongs in Since I see no objection to : fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [ ] [x] [x] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete.
Am I correct that this now awaits for a stabilization PR?
Yes.
Stabilization PR is up:
Change:
#[derive(Diagnostic)] #[diag(parse_box_syntax_removed)] <del> pub struct BoxSyntaxRemoved<'a> { </del> <ins> pub struct BoxSyntaxRemoved { </ins> #[primary_span] <del> #[suggestion( code = "Box::new({code})", applicability = "machine-applicable", style = "verbose" )] </del> pub span: Span, <del> pub code: &'a str, </del> <ins> #[subdiagnostic] pub sugg: AddBoxNew, } #[derive(Subdiagnostic)] #[multipart_suggestion( parse_box_syntax_removed_suggestion, applicability = "machine-applicable", style = "verbose" )] pub struct AddBoxNew { #[suggestion_part(code = "Box::new(")] pub box_kw_and_lo: Span, #[suggestion_part(code = ")")] pub hi: Span, </ins> } #[derive(Diagnostic)]

Discussion:
Found by grepping through the compiler via while reviewing an unrelated PR. File : File : : . or move source file . : . <details<summaryFull compiler output</summary</details:
Solution: Get rid of altogether and use a multi-part suggestion (, ).
Change:
# Using these defaults will download the stage2 compiler (see `download-rustc` # setting) and the stage2 toolchain should therefore be used for these defaults. download-rustc = "if-unchanged" <del> # Build the llvm-bitcode-linker as it is required for running nvptx tests llvm-bitcode-linker = true </del> [build] # Document with the in-tree rustdoc by default, since `download-rustc` makes it quick to compile.

Discussion:
With the latest , when I run a run-make test twice in a row, bootstrap rebuilds and : This has to be a recent regression, it didn't happen until ~yesterday. Confirmed with that it also happens for them.
Sounds suspiciously similar to
Yeah this is again caused by being enabled :laughing: Do you think that there's some more general solution to the rebuild problem?
Thanks for notifying me about this. I am travelling this weekend, meaning i might not have a chance to thoroughly investigate before Monday. (But I will at the latest be able to look on Monday). The last time it was due to dependency on the same crates with different rustflags. One from llbc-linker and one from some other tool (rustdoc?). The two different invocations maps to the same cache entry but is invalid between each other and thus triggers a rebuild. The solution last time was to mimic the rustflags being used other places in llbc-linker. That might be a good short term solution now as well. I don't know about the long term solution but it seems like either caching multiple versions of a crate or unifying the rustflag somewhere might be alternatives?
Of course, there's no rush, I just wanted to let you know, given that you already have some experience in debugging this :laughing: This seems rather brittle though, as you mention. I wonder what's so unique about this tool that it causes these rebuilds so often. You mentioned that we cannot share flags between all Step invocations. But maybe it would make sense to better share flags between at least this tool and other steps, rather than hardcoding selected flags? (as was done last time with the parallel compiler).
Actually, I wonder if we really need to enable this linker by default in all four bootstrap profiles.
Sure, seems fine to me. I didn't expect it to be a problem this frequently.
posted instead to disable this flag by default, I don't think it should be enabled for most contributors.
Change:
let write = |err: &mut ::io::Write| { let _ = writeln!(err, "thread '{}' panicked at '{}', {}:{}", name, msg, file, line); if log_backtrace { let _ = backtrace::write(err); <ins> } else if FIRST_PANIC.compare_and_swap(true, false, Ordering::SeqCst) { let _ = writeln!(err, "note: Run with `RUST_BACKTRACE=1` for a backtrace."); </ins> } };

Discussion:
Given this code, the failure message looks like this This is problematic as the useful information (the message passed to )is buried inside the sentence. It'd be better if the failure message was on its own line, something akin to: This format also allows for space to mention other useful information (e.g. issue ).
Is this still something we want to do? I have a small patch that implements something like this and would also but I'm not sure how many people really want another format for panic messages. Changing the format might also break existing tools (for example, there are several run-tests in this repo that expect a panic).
I'd be all for it, I still find those messages hard to read even after all these years.
you should submit it
The pull request didn't really fix this bug... should I make another bug like this, or is this a wontfix now?
Oh sorry, that's because I didn't change the original pull request message. Perhaps can comment on this?
This is somewhat of a wontfix for now, the discussion of concluded that we likely don't want to radically change the format for now due to the concurrency/verbosity reasons mentioned. If this becomes extra onerous in the future, however, we can consider reformatting these messages.

Rust developers are developers. Many will be used to using a debugger. Lets tell them straight up from the message how they can hook up their debugger without having to know anything about rust's name mangling algorithm.
Used as workaround in , but still discovered from other people instead of documentation. . Mentioning in the panic message and possibly in the documentation for might be a good idea. If nobody is already doing this, I will :)
Change:
fn raw_waker<W: Wake + Send + Sync + 'static>(waker: Arc<W>) -> RawWaker { // Increment the reference count of the arc to clone it. unsafe fn clone_waker<W: Wake + Send + Sync + 'static>(waker: *const ()) -> RawWaker { <del> unsafe { Arc::incr_strong_count(waker as *const W) }; </del> <ins> unsafe { Arc::increment_strong_count(waker as *const W) }; </ins> RawWaker::new( waker as *const (), &RawWakerVTable::new(clone_waker::<W>, wake::<W>, wake_by_ref::<W>, drop_waker::<W>),

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. --The feature gate for the issue is . <!-- 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. --- [x] Adjust documentation ([see instructions on rustc-dev-guide][doc-guide]) [x] Stabilization PR ([see instructions on rustc-dev-guide][stabilization-guide]) [stabilization-guide]: https://rustc-dev- [doc-guide]: https://rustc-dev- <!-- Include any open questions that need to be answered before the feature can be stabilised. --- [ ] Can we improve the docs phrasing on ? <!-- Include a list of all the PRs that were involved in implementing the feature. --- Initial PR in Stabilization PR in
Hello Would it make sense to also include similar methods for Rc? And possibly similar ones to both Weaks? It would be in part for the sake of completeness, but I do some manipulation like this in the arc-swap crate and if this would become the „official“ way, it would be nice to be supported on all the related types.
I think that's a great idea, and we should file follow-up issues to implement those.
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)] #![allow(unused)] fn f() { let mut x: Box<()> = Box::new(()); || { &mut x }; } #[rustc_error] fn main() {} //~ ERROR compilation successful </ins>

Discussion:
This works: This does not and gives a confusing error: The error:
This also gives a confusing error: The following works:
None of these examples don't compile today, so I'm presuming this is fixed and marking E-needstest.
Can I take this issue and put this into a run-pass test?
Sounds good to me, though compile-pass would probably be sufficient - grep for .
Ok. Will do. Btw, it looks like this commit was fixed by .
Change:
} let substs = substs.fold_with(self); if self.seen_opaque_tys.insert(def_id) { <del> let generic_ty = self.tcx.type_of(def_id); let concrete_ty = generic_ty.subst(self.tcx, substs); let expanded_ty = self.fold_ty(concrete_ty); </del> <ins> let expanded_ty = match self.expanded_cache.get(&(def_id, substs)) { Some(expanded_ty) => expanded_ty, None => { let generic_ty = self.tcx.type_of(def_id); let concrete_ty = generic_ty.subst(self.tcx, substs); let expanded_ty = self.fold_ty(concrete_ty); self.expanded_cache.insert((def_id, substs), expanded_ty); expanded_ty } }; </ins> self.seen_opaque_tys.remove(&def_id); Some(expanded_ty) } else {

Discussion:
There is a crate inside of Fuchsia whose compile times increased from ~500ms to ~120s in the last month of Rust compiler updates. It hasn't been easy so far to provide a minimal example, but I will keep working at it. Some bisecting revealed that it actually consisted of two performance regressions, both affecting the time spent in : The first regression occurred in the rollup , and the second occurred sometime in the two weeks between changes ... There is heavy use of async/await in the code, and I've identified a couple places where taking out makes the compile finish right away. This makes me suspect for the first regression, but I'm not sure. I'll update the issue as I have more information.
Interestingly, removing from either of these places makes the compile much faster. If I leave both in, it's slow, but taking one or both out makes it faster. Maybe there's some kind of cycle being created when both are left in? In fact, switching on actually causes a cycle error to be reported when there wasn't one before. This is really weird to me, but it may be a red herring. Removing one or both of the calls (or calls to the methods that create the futures) doesn't resolve the cycle error, even though it resolves the slowdown. of the error, for completeness.
I don't have a lot more information to put here, except that the compile time seems to increase with the size of a particular call graph of async fns (it's not binary slow/fast, but different gradations of slow). This continues to make it hard to minimize. I did some profiling, and noticed a lot of time being spent collecting items in . Unfortunately I couldn't see what was calling that function. There was some speculation that it could be from (cc who suggested this). See for more details, and some flame graphs of the profiles I ran.
visited for T-compiler triage. Assigning P-high based on labels applied by niko as part of async-await triage. Removing nomination label too.
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. // compile-flags: -O #![crate_type = "lib"] // CHECK-LABEL: @issue_34947 #[no_mangle] pub fn issue_34947(x: i32) -> i32 { // CHECK: mul // CHECK-NEXT: mul // CHECK-NEXT: mul // CHECK-NEXT: ret x.pow(5) } </ins>

Discussion:
Testcase: Produces the following asm in release mode: I would expect it to generate straight-line code with just three multiplies. It's possible this will be fixed by upgrading LLVM; there have been some recent changes to unrolling heuristics.
Assembly produced today is correct, and as expected. Closing.
Reopening as E-needstest. This should get a codegen test.
Change:
name = "clippy_lints" version = "0.0.212" dependencies = [ <del> "cargo_metadata", </del> <ins> "cargo_metadata 0.9.0", </ins> "if_chain", "itertools 0.8.0", "lazy_static 1.3.0",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool clippy-driver no longer builds. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! cc the PR reviewer, and nominating for compiler team prioritization.
triage: P-medium. Removing I-nominated.
There is opening PR to fix this: