jiebi/CodeConvo huggingface dataset:
Change:
assert_eq!(it.next(), Some(42u)); } <ins> #[test] fn test_fuse() { let mut it = 0us..3; assert_eq!(it.len(), 3); assert_eq!(it.next(), Some(0us)); assert_eq!(it.len(), 2); assert_eq!(it.next(), Some(1us)); assert_eq!(it.len(), 1); assert_eq!(it.next(), Some(2us)); assert_eq!(it.len(), 0); assert_eq!(it.next(), None); assert_eq!(it.len(), 0); assert_eq!(it.next(), None); assert_eq!(it.len(), 0); assert_eq!(it.next(), None); assert_eq!(it.len(), 0); } </ins> #[bench] fn bench_rposition(b: &mut Bencher) { let it: Vec<uint> = range(0u, 300).collect();

Discussion:
This should be in : This would require either implementing for (where ), or decoupling and (like in )
Change:
cfg_if::cfg_if! { if #[cfg(all( <del> target_arch = "arm", not(all(target_vendor = "apple", not(target_os = "watchos"))), not(target_os = "netbsd"), ))] { </del> <ins> target_arch = "arm", not(target_vendor = "apple"), not(target_os = "netbsd"), ))] { </ins> /// personality fn called by [ARM EHABI][armeabi-eh] /// <del> /// Apple 32-bit ARM (but not watchOS) uses the default routine instead /// since it uses "setjmp-longjmp" unwinding. </del> <ins> /// 32-bit ARM on iOS/tvOS/watchOS does not use ARM EHABI, it uses /// either "setjmp-longjmp" unwinding or DWARF CFI unwinding, which is /// handled by the default routine. </ins> /// /// [armeabi-eh]: https://web.archive.org/web/20190728160938/https://infocenter.arm.com/help/topic/com.arm.doc.ihi0038b/IHI0038B_ehabi.pdf #[lang = "eh_personality"]

Discussion:
Building project using should just work, but instead it fails to link to the and symbols. The exact error is: : This worked with , I'll try to bisect it myself. label O-watchos
Ugh, don't you just love it when the culprit is yourself? It's
Change:
trait_selection_unknown_format_parameter_for_on_unimplemented_attr = there is no parameter `{$argument_name}` on trait `{$trait_name}` .help = expect either a generic argument name or {"`{Self}`"} as format argument <ins> trait_selection_wrapped_parser_error = {$description} .label = {$label} </ins>

Discussion:
The following are some unexpected behaviors I see with the formatting strings in the attribute. I'm not sure that the attribute should actually be using std's format parsing, but if it is, the following seem like issues with the current implementation. Anything after the is ignored, and not included in the message output. Expectation: There should be a warning that the string is malformed. or These generate an error. However, my understanding of the attribute is that it tries to only generate warnings for things it doesn't understand. I would expect this to also generate a warning. This does not generate a warning or error. I would expect it to generate a warning that anything after the is ignored. This includes width, precision, debug formatting, etc. The error message generated with this is the type followed by a . I would expect this to generate a warning that the format arguments are not valid (similar to how works). : cc
I filled to hopefully address this.
Good catch! This should probably support a strict subset of formatting (only named arguments and no format options), and warn whenever the string is either not valid for or not in the supported subset. When it shows a warning, not sure what the behavior of the string should be -- maybe just take it as a literal without any interpolation?
Change:
<ins> // edition:2018 // run-rustfix fn foo() -> Box<impl std::future::Future<Output = u32>> { let x = 0u32; Box::new(async { x } ) //~^ ERROR E0373 } fn main() { let _foo = foo(); } </ins>

Discussion:
emits the following error The correct code needs the to be part of the block because it is a stack allocation that needs to be in the generator: Ideally, the error message would mention : thanks to for bringing this up! CC <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
We could also consider suggesting an block, similar to the hints we provide for closures.
Marking this as a focus item. assign
Change:
// Similarly to unix, we don't actually leave holes for the stdio file // descriptors, but rather open up /dev/null equivalents. These // equivalents are drawn from libuv's windows process spawning. <del> let set_fd = |&: fd: &Option<AnonPipe>, slot: &mut HANDLE, </del> <ins> let set_fd = |fd: &Option<AnonPipe>, slot: &mut HANDLE, </ins> is_stdin: bool| { match *fd { None => {

Discussion:
and are obsolete, but is not.
I think I spotted the problem, testing...
Fix in
Change:
#![allow(dead_code)] // runtime init functions not used during testing use os::windows::prelude::*; <ins> use sys::windows::os::current_exe; </ins> use sys::c; <del> use slice; use ops::Range; </del> use ffi::OsString; <del> use libc::{c_int, c_void}; </del> use fmt; <ins> use vec; use core::iter; use slice; use path::PathBuf; </ins> pub unsafe fn init(_argc: isize, _argv: *const *const u8) { }

Discussion:
An showed that removing the dependency from LLVM speed up its test suite by a huge amount. For us libstd doesn't depend on directly but it does depend on which depends on (according to the blog post). Specificaly it looks like , the same function as LLVM, is used by us! It'd be great to investigate removing the shell32 dependency from libstd (may be a few other functions here and there). We should run some tests on Windows to see if this improves rustc cycle times!
Based on my limited investigation, it's likely that replacing with a pure Rust equivalent should be good enough to get rid of the gdi32 dependency in things that only use libstd. So really someone just needs to write that pure Rust implementation which should be easy to do.
It would be nice to get rid of this in the compiler too. We spawn a lot of compiler instances during bootstrapping.
So now that the change has been implemented, have we actually investigated how much of an impact the change made?
Perf, an lolbench are both linux only. So nether help with this question. So don't waste your time like I did.
Here are just number for on 8 cores / 16 threads on Windows 10 v1809: Without the dependency: 333.012 325.587 320.650 With : 310.852 319.165 323.645
For what it's worth, though there's no good way to differentiate PR-to-PR due to very high variance, it does look like there was a recent regression in PR build times: <img width="1409" alt="image" src="https://user-"
I see that the CPU usage averages about 40% when running , so maybe we'd see some real improvements if we got rid of in the compiler too. Something is certainly holding things back.
Yeah, I saw that the compiler doesn't load . So there's probably some other reason why doesn't load all the cores.
Change:
use crate::cmp; <del> use crate::iter::{ adapters::zip::try_get_unchecked, adapters::SourceIter, FusedIterator, InPlaceIterable, TrustedLen, TrustedRandomAccess, }; </del> <ins> use crate::iter::{adapters::SourceIter, FusedIterator, InPlaceIterable, TrustedLen}; </ins> use crate::ops::{ControlFlow, Try}; /// An iterator that only iterates over the first `n` iterations of `iter`.

Discussion:
Look at this iterator. We all know that when ’s resulting implements , then the side-effects can be re-ordered. However, judging by the implementation of one would probably at least expect that it’s impossible to hit the without first either going through at least or first. Right? Well, here we go! on beta on stable 1.52.0 () label T-libs-impl, A-iterators, A-specialization, regression-from-stable-to-beta
cc
~As mentioned in the other issue, I think this is just another instance of ~ Edit: Nevermind, not really since it doesn't involve calling on Zip, rather this is about use of in Zip.
It’s related to . I guess the “random” aspect of is a bit weird for iterators like . You can do the same thing (accessing the from the center without “walking” there) with only, too, on stable already like so: <hrThis issue is only “really” a regression if out-of-order side-effects for iterators aren’t wanted.
steffahn brought up some general concerns about the implemention on () in I'll have to think some more about whether combining Take, TRA and backwards iteration is even doing the right thing under all circumstances, beyond the side-effects issue raised here. I am generally in favor of eliminating iterator side-effects that are not necessary to produce the final results. But of course that's currently undocumented and possibly surprising behavior and needs to be approved by the libs team, which hasn't happened so far. So while I like what it does it shouldn't have landed without discussion. I don't think so? At least that would be another implementation gap. That's what the whole thing is supposed to prevent. Oh, sure, that definitely is
https://rust- I'll submit a revert PR.
Change:
} } else { self.check_expr_has_type_or_error(base_expr, adt_ty, |_| { <del> let base_ty = self.check_expr(base_expr); </del> <ins> let base_ty = self.typeck_results.borrow().node_type(base_expr.hir_id); </ins> let same_adt = match (adt_ty.kind(), base_ty.kind()) { (ty::Adt(adt, _), ty::Adt(base_adt, _)) if adt == base_adt => true, _ => false,

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. --The following code: triggers a panic in the compiler (see below). All works as expected if I write . <!-- 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
Output on stable: (An awkward but correct error - without , the compiler uses autoref to resolve as which returns .) searched nightlies: from nightly-2021-10-16 to nightly-2021-11-28 regressed nightly: nightly-2021-11-10 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.1</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </details label regression-from-stable-to-beta
Probably ?
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium
I think this is a duplicate of , and I also put up a fix in (along with both in and in ) which has been waiting for a review for quite some time.. Not sure which one of our PRs should be approved, but at least one of them should :^) -- re: , I agree with Aaron that this is the simpler and more targeted fix for the bug, so I'll just close mine after this gets approved probably. (edit: made it clearer who I was referring to in the original comment - lol, sorry)
thanks for the note! I'll also add (as a self-reminder) that in Aaron also that might be a better fix.
Change:
<ins> // check-pass trait Foo { type FooT: Foo; } impl Foo for () { type FooT = (); } trait Bar<T: Foo> { type BarT: Bar<T::FooT>; } impl Bar<()> for () { type BarT = (); } #[allow(dead_code)] fn test<C: Bar<()>>() { } fn main() { } </ins>

Discussion:
Trait bounds on associated types seem to be required, not implied, when the trait in question mentions an associated type on a type parameter. Concretely, this code (or ) produces an error: despite the bound being required by the definition of itself, and in fact this means that the trait can never be mentioned. This similar example () that doesn't use an associated type in the trait parameter compiles: while this version (), which uses a third trait to avoid the self-reference, does not: Is this just a missing normalization step?
Pretty sure I encountered the same bug when specifying an associated type explicitly in a signature.
/cc you wanted to ensure this test case fell into the trait system rewrite.
I've just run into this as well, it seems. Here's a very simple example:

See the testcase here: I'd normally run this by a few people before filing an issue, but #rust is quiet on a Saturday night. ;-) thoughts?
Trait resolution basically doesn't know how to figure out that two types are equal in the case of "dual traits". This is one of the inevitable issues is going to hit in his Servo script bindings refactor I do wish we had a more formalized notion of type families that could be used to better instruct the compiler in these cases. was talking about this in , and I've personally found the need for a family-trait type situation more than once, both when modeling dualities and when modeling generic abstractions over sets of types like you're trying to do.
This appears to work today; E-needstest.
I don't think it works necessarily -- if you remove the bound that highlighted, you still get an error.
The example that expected to pass (and I think he is right that it should) is :
Current output:
Change:
AnnotationKind::Required, InheritDeprecation::Yes, InheritConstStability::No, <del> InheritStability::No, </del> <ins> InheritStability::Yes, </ins> |_| {}, ); }

Discussion:
Example: . This was fixed by adding stability attributes (), but the general problem remains that was able to land. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Found the bug. PR incoming. claim

As of current nightly rustc 1.65.0-nightly ( 2022-08-10): : Mentioning erstwhile tracking issue Mentioning in connection with .
"encountered unmarked API" &mdash; maybe it's that there is no #[stable] attribute on the enum variants, like there is in other stable enums? I'd have expected that to be caught during the libstd build, so we should fix whatever was supposed to catch it, not just add the attributes.
Indeed, I didn't realize that enum variants also needed stable attributes.
Change:
<ins> // compile-flags: --document-private-items #![crate_name = "foo"] use crate::bar::Bar as Alias; pub(crate) use crate::bar::Bar as CrateAlias; mod bar { pub struct Bar; pub use self::Bar as Inner; } // It's a fully private re-export so it should not be displayed. // @has 'foo/fn.bar.html' // @has - '//*[@class="rust item-decl"]/code' 'pub fn bar() -> Bar' pub fn bar() -> Alias { Alias } // It's public re-export inside a private module so it should be visible. // @has 'foo/fn.bar2.html' // @has - '//*[@class="rust item-decl"]/code' 'pub fn bar2() -> Inner' pub fn bar2() -> crate::bar::Inner { Alias } // It's a non-public, so it doesn't appear in documentation so it should not be visible. // @has 'foo/fn.bar3.html' // @has - '//*[@class="rust item-decl"]/code' 'pub fn bar3() -> Bar' pub fn bar3() -> CrateAlias { Alias } </ins>

Discussion:
rustdoc renders renamed imports () using the new, private name (e.g., in ). This is confusing behavior since the new name is an implementation detail. I think it should be using the original item's name instead. As an example, returns a , but the module it's defined in renames to . I would expect rustdoc to still show the item's definition name, but instead it shows the private name.
I don't think this should be changed until is fixed. Otherwise you could have two items shown with the same name and namespace in the same scope.
Code to reproduce: I don't think we need to wait for to be fixed as the fix for this doesn't impact it: if the re-export is not publicly reexported, we simply show the item underneath. When we will it will handle it the same.
Change:
type_ns: vec![Rib::new(start_rib_kind)], macro_ns: vec![Rib::new(start_rib_kind)], }, <ins> last_block_rib: None, </ins> label_ribs: Vec::new(), lifetime_ribs: Vec::new(), lifetime_elision_candidates: None,

Discussion:
When the error should mention bindings that are outside of the scope but within the same item <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Do you think we should suggest in this scenario? My local dev branch will suggest:
I removed it.
Change:
LL | m!{ S<u8> } |      ^^^^ <del> error[E0577]: expected module, found struct `S` </del> <ins> error[E0433]: failed to resolve: `S` is a struct, not a module </ins> --> $DIR/visibility-ty-params.rs:6:5 | LL | m!{ S<u8> } <del> |     ^^^^^ not a module </del> <ins> |     ^ `S` is a struct, not a module </ins> error: unexpected generic arguments in path --> $DIR/visibility-ty-params.rs:10:10

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
glacier ""
searched nightlies: from nightly-2022-10-05 to nightly-2023-03-16 regressed nightly: nightly-2022-10-12 searched commit range: regressed commit:
Newer version of cargo-bisect-rustc can bisect through rollups
The one that is not released yet? :smile: Thx, will install git then.. :)
label +S-bug-has-mcve
Change:
<ins> warning: unused import: `foo::foo1` --> $DIR/use-redundant-issue-78894.rs:44:13 | LL |         use foo::foo1; |             ^^^^^^^^^ | note: the lint level is defined here --> $DIR/use-redundant-issue-78894.rs:4:9 | LL | #![warn(unused_imports)] |         ^^^^^^^^^^^^^^ warning: 1 warning emitted </ins>

Discussion:
This (very contrived) example emits a warning: Playground: This is a false positive because removing results in a compilation error: Same for and .
It seems this regressed somewhere between 1.34.0 and 1.35.0
More accurately, it looks like the false positive has been present since the introduction of the warning in
I was actually a little surprised that did not cause a compilation error due to two imports of the same name at the same level.
I got something similar while implementing ops::Div when removed, it errors
This issue no longer reproduces and can be closed when a corresponding test is .
Change:
env, crate::ty::EarlyBinder::bind(constant.const_), ); <del> let Some(bits) = mono_literal.try_eval_bits(tcx, env) else { bug!("Couldn't evaluate constant {:?} in mono {:?}", constant, instance); }; bits </del> <ins> mono_literal.try_eval_bits(tcx, env) </ins> }; let TerminatorKind::SwitchInt { discr, targets } = &block.terminator().kind else {

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. --I encountered an ICE while playing with 's that has to do with its comptime assertions. I have not been able to reproduce the ICE when inlining the constant value in which the checks are performed. Perhaps it is related with the fact that originally there was a crate boundary? I have an inkling const blocks' merger might be to blame. <!-- 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
It would be useful to have a minimal example that doesn't involve the entire tagged_ptr crate.
Reduced: , needs This bisects to cc label A-monomorphization S-has-mcve -E-needs-mcve
ye olde "compiler must not crash on invalid code" problem
PR with a fix is up. Thanks for catching this before the bug hit beta
No, thanks to you all for not only fixing it, but running this amazing project every day. I hope I have more time in the future so that I can spend it here and be a part of this.
Change:
use std; use std::collections::HashMap; <ins> use std::iter::AdditiveIterator; </ins> use std::rc::Rc; use syntax::ast; use syntax::ast::{DUMMY_NODE_ID, Ident};

Discussion:
Minimal test case: If 1024 doesn’t do it for you, try bumping it upwards. ought to do it. Just don’t try numbers like a million or you’ll be waiting a while before it crashes. And if you have anything like systemd-coredump start automatically, it’ll be busy for a while as well… I guess there are a few areas where [T, ..N] is not handled well for large N. (Additional keywords: sized array.)
Running it under GDB shows that it’s flipping back and forth between two functions recursively: Whatever this recursive algorithm is needs to be made non-recursive.
There is a slight difference between this minimal test case, and the original issue . If I reduce the size of the array to 10 bytes in , compilation never completes (no error is raised). If I reduce the size of the array in this test case to 10 bytes, it compiles.
could you try to narrow down the test from , in the manner that chris-morgan has done here, but preserving the behavioral difference you are observing?
I will try my best (this lunchtime), but I only have three hours experience with Rust so far. Every few lines of code written or modified requires 15 minutes of Googling the docs. (This learning curve is still much less steep than Haskell's was.)
feel free to drop by , you’ll get any help you need there quickly.
I was mistaken. I had a subsequent, chained, command on the command line which produced no output and hung. I mistook this for the compiler hanging.
okay, great, thanks for the update! (I now feel better about asking you to do the narrowing rather than attempting to do it myself.) ;)
Change:
let mut nonelided_generic_args: bool = false; let elide_lifetimes = generic_args.args.iter().all(|arg| match arg { <del> GenericArg::Lifetime(lt) => lt.is_elided(), </del> <ins> GenericArg::Lifetime(lt) if lt.is_elided() => true, GenericArg::Lifetime(_) => { nonelided_generic_args = true; false } </ins> _ => { nonelided_generic_args = true; true

Discussion:
(From the Playground.) Note that the uses of , , and don't include their lifetimes. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
/// continuing with unwinding. It's also used for the non-parallel code to ensure error message /// output match the parallel compiler for testing purposes. pub struct ParallelGuard { <del> panic: Mutex<Option<Box<dyn Any + Send + 'static>>>, </del> <ins> panic: Mutex<Option<IntoDynSyncSend<Box<dyn Any + Send + 'static>>>>, </ins> } impl ParallelGuard { pub fn run<R>(&self, f: impl FnOnce() -> R) -> Option<R> { catch_unwind(AssertUnwindSafe(f)) .map_err(|err| { <del> *self.panic.lock() = Some(err); </del> <ins> let mut panic = self.panic.lock(); if panic.is_none() || !(*err).is::<FatalErrorMarker>() { *panic = Some(IntoDynSyncSend(err)); } </ins> }) .ok() }

Discussion:
found while checking with When you run the snipped above with , rustc panics, but the exit status is as if there was just a normal compiler error, instead of a . This tripped up automatic ice-reduction that relies on a somewhat familiar exit code when the program crashes :sweat_smile:
is the problematic line here that turns ICEs into "normal" fatal errors that call exit(1) though actually at least with the non parallel compiler i'm very surprised that we're ending up in a query in the first place after panicking.
It seems that current stable does correctly exit with here... I bisected the exit code 101 -exit code 1 change with a crashing file ( ) and got to Regression in nightly-2023-08-31 Regression in cc /
WG-prioritization assigning priority (). label -I-prioritize +P-medium