jiebi/CodeConvo huggingface dataset:
Change:
use super::{BorrowedBuf, BufReader, BufWriter, Read, Result, Write, DEFAULT_BUF_SIZE}; use crate::alloc::Allocator; use crate::cmp; <ins> use crate::cmp::min; </ins> use crate::collections::VecDeque; use crate::io::IoSlice; use crate::mem::MaybeUninit;

Discussion:
Reported by a lz4flex user I created a small repo to demonstrate on a minimal example. BorrowedCursor::ensureinit from this PR seems exhibit exponential cost. The program creates a Vec and reads it in chunks of 32kb. Size is specified as a command line argument (100MB-400MB). (If your default is 1.73) <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-stable -regression-untriaged --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Maybe try (tutorial: https://rust-) to find which PR caused this?
Really nice bisect tool. From the commit list in that Auto merge it seems to be
cc author
The loop creates a new on each iteration, which is fine if the reader can fill the provided buffer in one go but does unnecessary work on short reads. Should be easy to fix. claim
Any chance of getting this fix in a backport to 1.73?
Change:
<del> // Copyright 2012 The Rust Project Developers. See the COPYRIGHT </del> <ins> // Copyright 2012-2014 The Rust Project Developers. See the COPYRIGHT </ins> // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. //

Discussion:
This looks like , but I'm running . The error message was With this stacktrace: I'm on an i686 Ubuntu 14.04.1 LTS Vagrant VM (the ) on OS X 10.9.5
Actually, I just took another look at the command line, and it had . That's probably where the value came from, but I don't know if it's the expected error message.
Yep, this should definitely have a better error message.
Do you happen to have a code example that triggers this?
I don't have code, but specifying a value for seemed to fix the problem, so I think that's it.
fixing it now.
Change:
<ins> // edition:2021 async fn foo() { inner::<false>().await //~^ ERROR: function takes 2 generic arguments but 1 generic argument was supplied //~| ERROR: type inside `async fn` body must be known in this context //~| ERROR: type inside `async fn` body must be known in this context //~| ERROR: type inside `async fn` body must be known in this context //~| ERROR: type inside `async fn` body must be known in this context //~| ERROR: type inside `async fn` body must be known in this context } async fn inner<T, const PING: bool>() {} fn main() {} </ins>

Discussion:
It appears that the is no longer working. I got this after running on a build that had no issues. I then ran and to do a fresh build and still got the error. I know it isn't related to incremental builds and it's currently giving me a headache.
Can you share some code that produced this error?
The link recently changed. If you don't mind, where did you find this link? (If it's somewhere official, we should change it.)
There is a link in the ICE message in "older" compilers. See for adding the template back
Thanks for explaining! Well, that's really easy to fix; all we need is time travel!
It was part of the compiler output on 1.66.1. Sorry, I can't share the code. I was in the middle of refactoring something and had this pop up. I was able to compile it on nightly and when the compile errors went away the stable compiler no longer had the issue. The project I was working on is ~2600 lines of code and I wouldn't even know where to start. If it happens again I'll do commits so that I can figure out what change triggered this.
Hi!

I seem to have found this ICE or a similar one with this output: It also reproduces in stable 1.66.1, However it doesn't reproduce on stable 1.66.1 or the current nightly (the below version for cargo, unfortunately the rustc version for nightly is hard) The reason I think I have the same or a similar ICE is because, well, it starts out the same as well as having the same query stack: I'll try to reproduce it on Friday ish to bisect where / when this happened, and why (so that we can probably mark it as already fixed, unless I happen to uncover a root cause that still exists)
MRE Full ICE: <details<summaryFull ICE</summary</detailscargo-bisect-rustc for start: Regression in searched nightlies: from nightly-2022-10-15 to nightly-2022-10-30 regressed nightly: nightly-2022-10-21 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: aarch64-apple-darwin Reproduce with: </detailscargo-bisect-rustc for end: Regression in searched nightlies: from nightly-2022-10-21 to nightly-2023-02-24 regressed nightly: nightly-2022-11-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: aarch64-apple-darwin Reproduce with: </details
Reading that leads me to which fixed
Change:
if !self.tcx.has_typeck_results(def_id) { return false; } <del> // We're emitting a suggestion, so we can just ignore regions let fn_sig = self.tcx.fn_sig(def_id).skip_binder(); </del> <ins> // FIXME: Instead of exiting early when encountering bound vars in // the function signature, consider keeping the binder here and // propagating it downwards. let fn_sig = if let Some(fn_sig) = self.tcx.fn_sig(def_id).no_bound_vars() { fn_sig } else { return false; }; </ins> let other_ty = if let FnDef(def_id, _) = *other_ty.kind() { if !self.tcx.has_typeck_results(def_id) {

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</detailsNOTE: The bug is found by our work-in-progress compiler testing tool Kira, and the test program is reduced/minimized by <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It also fails for every comparison of and
I found another potentially related weirdness: This fails with: But this (without the argument) fails with a different error, even though there should be no difference as is not used: EDIT: Apparently this is intended behavior, see .
searched nightlies: from nightly-2019-01-01 to nightly-2020-10-13 regressed nightly: nightly-2020-05-03 searched commits: from to regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.5.2</summaryHost triple: x86_64-apple-darwin Reproduce with: </details
Darn, is it really the bitcode commit again? Or did it happen sometime around then? Cc
This bisection is incorrect due to:
Marking this as P-
claim
You have to write if you want to assign this issue.
Thanks bro. claim
Change:
impl_assoc_ty.defaultness(tcx.defaultness(impl_fn_def_id)); // Copy generics_of the trait's associated item but the impl as the parent. <del> // FIXME(-Zlower-impl-trait-in-trait-to-assoc-ty) resolves to the trait instead of the impl // generics. </del> <ins> // FIXME: This may be detrimental to diagnostics, as we resolve the early-bound vars // here to paramswhose parent are items in the trait. We could synthesize new params // here, but it seems overkill. </ins> impl_assoc_ty.generics_of({ let trait_assoc_generics = tcx.generics_of(trait_assoc_def_id); let trait_assoc_parent_count = trait_assoc_generics.parent_count;

Discussion:
Minimal example (): outputs In the example, the implementation is irrelevant. The definition itself is the cause for error. Removing either the lifetime or the results in successful compilation as expected. I don't understand why it's causing a cycle error, but intuitively I don't see why it should be. Introducing an trait with a blanket implementation is a possible workaround and what I'll be doing while the issue exists.
Change:
// functions without #[rustc_promotable] if self.tcx.is_promotable_const_fn(def_id) { is_const_fn = true; <ins> is_promotable_const_fn = true; } else if self.tcx.is_const_fn(def_id) { is_const_fn = true; </ins> } } else { // stable const fn or unstable const fns with their feature gate

Discussion:
: produces cc
Not that this fixes the issue, but and aren't necessarily guaranteed to have the same representation without or on both and .
minified: is this a victim of the backwards algorithm for promotion? Just a hunch, but it might have promoted away the call to and then end up trying to promote the , but it's not in the place where it was expected, because it now lives inside the promoted. So it ends up trying to promote an argument in a basic block that was already promoted away
thanks , I'll update the PR that triggered this - for context
As a workaround until we fix this ICE, you can introduce an intermediate explicit constant for the argument to . Or is this part of a user-exposed API?
This is part of a user-exposed API, but that workaround should allow me to at least get the const tests running.
It won't remove the definition if there's more than one use (unless this is fallout from your changes?)
There's only one use. I don't see how my changes could have caused this, but it seems possible. I'll do a bisection
Oh, I see, is and that's missing a check like:
Fix instructions: Add a which, like the variable, is used to mark blocks whose terminator has been promoted out. skip promoting all such terminators when encountering said block id in a ()
You can use a , although I'm not even sure it's necessary. A promoted call ends up as a , so you could just skip it based on that?
Change:
let expr = self.mk_expr(lo.to(self.prev_token.span), ExprKind::Lit(literal), attrs); self.maybe_recover_from_bad_qpath(expr, true) } <del> None => Err(self.expected_expression_found()), </del> <ins> None => self.try_macro_suggestion(), </ins> } }

Discussion:
Old documentation and blogposts will never be updated to not talk about the macro. is It should provide structured suggestions to either use or : This request is similar in spirit to and feels like a subset of . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Would it be fine if I modified and check if the keyword is used, or is there another way to tackle this issue
Change:
<ins> error[E0609]: no field `await` on type `await_on_struct_missing::S` --> $DIR/suggest-switching-edition-on-await.rs:9:7 | LL |     x.await; |       ^^^^^ unknown field | = note: to `.await` a `Future`, switch to Rust 2018 = help: set `edition = "2018"` in `Cargo.toml` = note: for more on editions, read https://doc.rust-lang.org/edition-guide error[E0609]: no field `await` on type `await_on_struct_similar::S` --> $DIR/suggest-switching-edition-on-await.rs:22:7 | LL |     x.await; |       ^^^^^ help: a field with a similar name exists: `awai` | = note: to `.await` a `Future`, switch to Rust 2018 = help: set `edition = "2018"` in `Cargo.toml` = note: for more on editions, read https://doc.rust-lang.org/edition-guide error[E0609]: no field `await` on type `std::pin::Pin<&mut dyn std::future::Future<Output = ()>>` --> $DIR/suggest-switching-edition-on-await.rs:31:7 | LL |     x.await; |       ^^^^^ unknown field | = note: to `.await` a `Future`, switch to Rust 2018 = help: set `edition = "2018"` in `Cargo.toml` = note: for more on editions, read https://doc.rust-lang.org/edition-guide error[E0609]: no field `await` on type `impl Future<Output = ()>` --> $DIR/suggest-switching-edition-on-await.rs:40:7 | LL |     x.await; |       ^^^^^ | = note: to `.await` a `Future`, switch to Rust 2018 = help: set `edition = "2018"` in `Cargo.toml` = note: for more on editions, read https://doc.rust-lang.org/edition-guide error: aborting due to 4 previous errors For more information about this error, try `rustc --explain E0609`. </ins>

Discussion:
Trivial example: Output on current nightly: Ideally the error message would suggest using the 2018 edition.
Part of
Change:
#[cfg(stage1)] #[cfg(stage2)] <ins> #[cfg(stage3)] </ins> fn mk_tests(cx: &TestCtxt) -> @ast::item { let ext_cx = cx.ext_cx;

Discussion:
Kind of annoying to not have this imported by default.
Would it be an option to implement WriterUtils functionality as default methods on Writer? A similar situation exists with ReaderUtil too.
yes, that is a good use case for default methods, but they don't work yet.
Change:
/// /// Deliberately don't inline the main sorting routine entrypoint to ensure the /// inlined insertion sort i-cache footprint remains minimal. <del> #[cfg(not(feature = "optimize_for_size"))] </del> <ins> #[cfg(not(any(feature = "optimize_for_size", target_pointer_width = "16")))] </ins> #[inline(never)] fn ipnsort<T, F>(v: &mut [T], is_less: &mut F) where

Discussion:
Run Or And you'll get this diagnostic (cargo miri setup makes it a warning, lol): I don't know what effect this has at runtime but it can't be good.
It's worse than one might think, because many AVR microarchitectures, including the atmega328 we nominally support, have only 2KiB of SRAM, which means that this line is literally impossible:
these targets should probably use some of the code in with perhaps a few more tweaks.
Good to know, 16-bit wasn't something we had in mind during development, in terms of less standard targets, we did test big endian with miri. I agree with the code in would be a better fit for such targets. What kind of tweaks did you have in mind?
There are other places in driftsort and ipnsort that use stack arrays, e.g: They are all size bound to <= 4KiB through various means, but still a poor fit for tiny chips.
I think that's necessary, I don't believe driftsort could ever meaningfully run on machines this small.
You already figured it out: dropping all the stack arrays to the absolute minimum. Note that you are not obligated to fix these targets, as usual.
I think it should be a single additional in the impl, so I don't mind doing it.
Yeah, we'd get CI failures way too often if we errored on warnings for tier 3 targets.
Related:
Who is using Tier 3 targets in CI?
Miri is, by running a test with . We should probably change that.
Thinking a bit more about it, is there any scenario where you'd compile Rust for 16-bit targets and don't want to use ? Independent of sort. I'd think that such targets are always binary-size limited and welcome any reduction of it.
Change:
err.downgrade_to_delayed_bug(); } <ins> self.find_builder_fn(&mut err, rcvr_ty, source); </ins> if tcx.ty_is_opaque_future(rcvr_ty) && item_name.name == sym::poll { err.help(format!( "method `poll` found on `Pin<&mut {ty_str}>`, 

Discussion:
Consider the following code: This fails with an error that simply states that is not available: The intent is fairly clear: we want to construct a new using a method that follows the for constructors, but that method is not available. Instead the solution is likely to be either or : When is not available it'd be ideal if the compiler could suggest alternatives. A first heuristic for which methods to suggest be methods on the same struct that don't take any params, have as their return type, and aren't implemented through any trait. For this would include and . But not , , and . I'm not too sure how to structure the help message exactly, but I could imagine something along these lines might work: cc/
Seems like es should be to the standard library to fix this.
This seems to be the same as
Closing in favor of that.
For the example I brought up, how would an work? The method does not exist on . So it shouldn't qualify as an alias? Additionally this is intended as an automated mechanism to improve the quality of diagnostics, rather than a manual mechanism (like attributes) which would need to be opted into. While both cases do touch on improving diagnostics for missing methods, I don't think these are equivalent.
No but does exist, so e.g., on it could add the information necessary (see e.g. on ) for the compiler to provide the diagnostic. But I suppose the heuristic you've suggested might work without attributes, although I suspect it would suggest too many false positives, but let's reopen I guess.
what do you think of the following? <img width="779" alt="Screenshot 2023-10-20 at 6 13 57 PM" src=""
oh I love it!
Change:
check!(extdeps, &root_path); // Checks over tests. <ins> check!(tests_placement, &root_path); </ins> check!(debug_artifacts, &tests_path); check!(ui_tests, &tests_path); check!(mir_opt_tests, &tests_path, bless);

Discussion:
A PR modifying an existing test now has a merge conflict e.g. but a PR adding a new test doesn't e.g. , and I'm worried if a new test is to by accident. Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Mentoring instructions: Add a new module to src/tools/tidy, then call the check from See the surrounding code for examples of how tidy checks work.
I am confused as to why this was not a blocker for moving the tests
"I didn't think of it"
claim
Change:
<ins> // Copyright 2015 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. pub struct PublicType; struct PrivateType; pub trait PublicTrait { type Item; } trait PrivateTrait { type Item; } impl PublicTrait for PublicType { type Item = PrivateType;  //~ ERROR private type in exported type signature } // OK impl PublicTrait for PrivateType { type Item = PrivateType; } // OK impl PrivateTrait for PublicType { type Item = PrivateType; } // OK impl PrivateTrait for PrivateType { type Item = PrivateType; } fn main() {} </ins>

Discussion:
AFAIK, you can't put private types in "public" items (public as in marked with ). is not explicitly marked with , but for all intent and purposes all the methods in a trait are public if the trait is public. So, I think the should be rejected by the privacy checker. (Or, I could be wrong and this is "correct" behavior - and this wouldn't be the first time that the privacy/module system allows things that I find ) cc
I agree, I think this may have just been accidentally overlooked when implementing associated types.
On Sat, Feb 28, 2015 at 10:59:14PM -0800, Alex Crichton wrote: Yes, that. There was language in the RFC describing trait item signatures and how they should be treated, and I think we just failed to extend that to associated types. Definitely a bug.
triage: P-backcompat-lang (1.0 beta)
Note also that is still open.
Change:
"rustc_hir", "rustc_index", "rustc_infer", <ins> "rustc_lint_defs", </ins> "rustc_macros", "rustc_middle", "rustc_parse_format",

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: This should probably continue to compile as before, unless proven to be equivalent. Instead, this happened: The detection for seems to be a little too aggressive, so it's flagging the coercion as feature-gated in beta even though a deref coercion is available: Playground: <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.55.0 : <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --<!-- Include a backtrace in the code block by setting in your environment. E.g. . --<!--<details<summaryBacktrace</summary<p</p</details--(not applicable) <!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged -- modify labels: +regression-from-stable-to-beta -regression-untriaged
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Bisection: searched nightlies: from nightly-2020-01-01 to nightly-2021-09-23 regressed nightly: nightly-2021-08-01 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
There is a that discusses this issue. Tagging this with T-lang since this is a change in semantics.

label +A-traits +F-trait_upcasting +T-lang +T-compiler
I'm not sure what the proper procedure is in this case, but I just noticed this hit stable in 1.56.0 (without the lint appearing beforehand) and broke my crate I'll work around it on my end, since I need this to continue work on a downstream crate.
Hmm, it seems that the fix didn't get backported to 1.56. Does 1.57-beta work?
It does indeed: The playground uses as of writing this.
Change:
<ins> #![feature(specialization)] #![allow(incomplete_features)] struct MyStruct {} trait MyTrait { type MyType: Default; } impl MyTrait for i32 { default type MyType = MyStruct; //~^ ERROR: the trait bound `MyStruct: std::default::Default` is not satisfied } fn main() { let _x: <i32 as MyTrait>::MyType = <i32 as MyTrait>::MyType::default(); } </ins>

Discussion:
This snippet is found in . Reduced: :
Nitpick: There's no need to put the two into different functions, you can put them both in .
Like , when using an anonymous binding (), the above code :
No longer ICEs since

With specialization, it is possible to define a default associated type that does not fulfill its trait bounds. Here is a minimal example, that surely should not compile, but does with rustc 1.35.0-nightly: Unsurprisingly, adding the main function causes an ICE. Error message and backtrace (compiled at the playground):
Triage: the latest nightly rejects the code, marking as E-needs-test.

This code generates an ICE with this message. Replacing by makes the code to compile and run fine, which is strange because ! does not implements . By removing the specialization the compiler refuses to compile the code with the error:
The ICE has been fixed in the latest nightly, marked as E-needstest
Thanks Indeed, the example compiles fine in nightly ( 2019-11-12), however, replacing the main function by these two generates the same ICE.
ah, thanks for the update! I confirmed it ()
Triage: the ICE doesn't occur anymore with the latest nightly, marking as E-needs-test.

I was attempting to figure out the feature landscape for , and I found this ICE when playing with it and specialization:
The given code builds fine on current nightly.
This is still an ICE on current nightly when not .
This code compiles without a problem whether I do or using current nightly: . Tested on Windows 10 x64 and Ubuntu x64.
Really? But on the playground, the ICE still appears. Can you check the above link?
Yes, I get an ICE in the playground when I just build.
It does ICE when using instead of .
You need or , not . It seems like a still ICE to me.
Triage: the latest nightly rejects the code without an ICE. Marking as E-needs-test.