jiebi/CodeConvo huggingface dataset:
Code change:
I may have found a bug in the compiler. The entirety of the code to reproduce this bug is this: The program should build successfully, assuming the rustc type checker does not detect any errors at the level of the Rust type system. The rustc type checker seems happy with the program. However, presumably after the LLVM IR generation phase, and during some IR verification phase, I get this type error:
Reduced:
I thought we already fixed that by adding casts. One possible fix that might be less harmful would be to give all types that are subtyping-equivalent the same LLVM type. They should be having the same layout anyway, and their fields should be subtyping-equivalent (because that's what subtyping-equivalence means). The other option would be to insert casts when subtyping is taking place.
This looks like a new instance of . cc
was just an instance of the general problem, we just started generating named types for trait objects then, which made the problem show up in more cases. I agree with first proposal, i.e. destroy the distinction ahead of time. We're only wasting time by inserting casts and LLVM wastes time ignoring those casts (insert rant about how counterproductive LLVM's types are).
Reduced to its essence:
An example that my previous approach will not make compile (but currently gives an ICE outputtypeparametermismatch):
Nah you can do it without an ICE, but you're still within deep ICE territory
This is making me suspect, that when we get higher-ranked type bounds, finding a "canonical form for subtyping" will be impossible (note: don't be so sure. You can't? (shouldn't?) have higher-ranged type bounds in trait objects, so life might be better). Might as well insert casts. Note that my old approach has problems with anonymization in invariant types:
marking this as p-medium as per the
labels +T-types This seems like a problem around higher ranked normalization etc, so we are tagging as T-types. We think it may have been fixed as a side-effect of some LLVM change or other (cc for the details).
Seems to be fixed since 1.23.
Triage: The issue hasn't been fixed actually, at least on CI (CI stderr from ):
That's interesting. It doesn't fail in a playground. Is this a debug assert now or something?
The build says so maybe this is fixed with nighty that uses llvm but llvm 13 still causes problems?
Likely, we could use if so. Is there a CI builder that uses a newer LLVM on bors?
Yeah, this is fixed by LLVM using its opaque pointers, so that's why it's possibly broken on LLVM 13?
Re-submitted a PR with :

Related discussion:
text: <ins> // run-pass // ^-- The above is needed as this issue is related to LLVM/codegen. // min-llvm-version:15.0.0 // ^-- The above is needed as this issue is fixed by the opaque pointers. fn main() { type_error(|x| &x); } fn type_error<T>( _selector: for<'a> fn(&'a Vec<Box<dyn for<'b> Fn(&'b u8)>>) -> &'a Vec<Box<dyn Fn(T)>>, ) { } </ins>
Code change:
The following example ICEs yields (Same is true on stable.)
That's because the ObjectCandidate code is not normalizing the upcast trait refs. Should we wait for Chalk for the fix?
Hitting this error, any updates?
Triage: no longer ICEs.
It's still an ICE, note that we should build/run the snippet to check it ().
Triage: It's no longer ICE with the latest nightly, I think it's fixed by .

Related discussion:
text: <ins> // check-pass trait Mirror { type Other; } #[derive(Debug)] struct Even(usize); struct Odd; impl Mirror for Even { type Other = Odd; } impl Mirror for Odd { type Other = Even; } trait Dyn<T: Mirror>: AsRef<<T as Mirror>::Other> {} impl Dyn<Odd> for Even {} impl AsRef<Even> for Even { fn as_ref(&self) -> &Even { self } } fn code<T: Mirror>(d: &dyn Dyn<T>) -> &T::Other { d.as_ref() } fn main() { println!("{:?}", code(&Even(22))); } </ins>
Code change:
The following example ICEs yields (Same is true on stable.)
That's because the ObjectCandidate code is not normalizing the upcast trait refs. Should we wait for Chalk for the fix?
Hitting this error, any updates?
Triage: no longer ICEs.
It's still an ICE, note that we should build/run the snippet to check it ().
Triage: It's no longer ICE with the latest nightly, I think it's fixed by .

Related discussion:
text: <ins> fn t7p<A, B, C>(f: impl Fn(B) -> C, g: impl Fn(A) -> B) -> impl Fn(A) -> C { move |a: A| -> C { f(g(a)) } } fn t8n<A, B, C>(f: impl Fn(A) -> B, g: impl Fn(A) -> C) -> impl Fn(A) -> (B, C) where A: Copy, { move |a: A| -> (B, C) { let b = a; let fa = f(a); let ga = g(b); (fa, ga) } } fn main() { let f = |(_, _)| {}; let g = |(a, _)| a; let t7 = |env| |a| |b| t7p(f, g)(((env, a), b)); let t8 = t8n(t7, t7p(f, g)); //~^ ERROR: expected a `Fn<(_,)>` closure, found `impl Fn<(((_, _), _),)> } </ins>
Code change:
The following example ICEs yields (Same is true on stable.)
That's because the ObjectCandidate code is not normalizing the upcast trait refs. Should we wait for Chalk for the fix?
Hitting this error, any updates?
Triage: no longer ICEs.
It's still an ICE, note that we should build/run the snippet to check it ().
Triage: It's no longer ICE with the latest nightly, I think it's fixed by .

Related discussion:
text: <ins> error[E0277]: expected a `Fn<(_,)>` closure, found `impl Fn<(((_, _), _),)>` --> $DIR/issue-59494.rs:21:22 | LL | fn t8n<A, B, C>(f: impl Fn(A) -> B, g: impl Fn(A) -> C) -> impl Fn(A) -> (B, C) |                                             ---------- required by this bound in `t8n` ... LL |     let t8 = t8n(t7, t7p(f, g)); |                      ^^^^^^^^^ expected an `Fn<(_,)>` closure, found `impl Fn<(((_, _), _),)>` | = help: the trait `Fn<(_,)>` is not implemented for `impl Fn<(((_, _), _),)>` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>
Code change:
The following example ICEs yields (Same is true on stable.)
That's because the ObjectCandidate code is not normalizing the upcast trait refs. Should we wait for Chalk for the fix?
Hitting this error, any updates?
Triage: no longer ICEs.
It's still an ICE, note that we should build/run the snippet to check it ().
Triage: It's no longer ICE with the latest nightly, I think it's fixed by .

Related discussion:
text: <ins> // check-pass pub trait Trait1 { type C; } struct T1; impl Trait1 for T1 { type C = usize; } pub trait Callback<T: Trait1>: FnMut(<T as Trait1>::C) {} impl<T: Trait1, F: FnMut(<T as Trait1>::C)> Callback<T> for F {} pub struct State<T: Trait1> { callback: Option<Box<dyn Callback<T>>>, } impl<T: Trait1> State<T> { fn new() -> Self { Self { callback: None } } fn test_cb(&mut self, d: <T as Trait1>::C) { (self.callback.as_mut().unwrap())(d) } } fn main() { let mut s = State::<T1>::new(); s.test_cb(1); } </ins>
Code change:
The following example ICEs yields (Same is true on stable.)
That's because the ObjectCandidate code is not normalizing the upcast trait refs. Should we wait for Chalk for the fix?
Hitting this error, any updates?
Triage: no longer ICEs.
It's still an ICE, note that we should build/run the snippet to check it ().
Triage: It's no longer ICE with the latest nightly, I think it's fixed by .

Related discussion:
text: <ins> // check-pass fn any<T>() -> T { loop {} } trait Foo { type V; } trait Callback<T: Foo>: Fn(&T, &T::V) {} impl<T: Foo, F: Fn(&T, &T::V)> Callback<T> for F {} struct Bar<T: Foo> { callback: Box<dyn Callback<T>>, } impl<T: Foo> Bar<T> { fn event(&self) { (self.callback)(any(), any()); } } struct A; struct B; impl Foo for A { type V = B; } fn main() { let foo = Bar::<A> { callback: Box::new(|_: &A, _: &B| ()) }; foo.event(); } </ins>
Code change:
reduced from num_cpus: built with yields cc `
What’s the target? Ah, never mind, I missed that its .
More minimal: Issue does not occur on stable (or 1.30.0 nightly), but occurs on rustc beta.
Marking T-libs as that is likely to be an issue within implementation of , but I didn’t investigate further.
Excerpt: Clearly both of those adjacent i32 aren't going to be 8-byte aligned ^^ It seems that we're storing to an key with wrong alignment for some reason.
Don't need to look particularly far, this code generates It looks like some code is assuming that both elements in a scalar pair have the same alignment as the whole pair.
Probably the easiest way to get to the root cause is to bisect.
This code is very likely the culprit: It takes the 0 and 1 GEPs, but uses the same alignment, without offset adjustment.
Ouch, that's bad. To obtain the alignment for both fields, we need to do: Note that we can't use because the components do not match fields (the latter come from the user type definitions, whereas the former are extracted as an optimization).

Related discussion:
text: bx.store_with_flags(val, dest.llval, dest.align, flags); } OperandValue::Pair(a, b) => { <del> for (i, &x) in [a, b].iter().enumerate() { let llptr = bx.struct_gep(dest.llval, i as u64); let val = base::from_immediate(bx, x); bx.store_with_flags(val, llptr, dest.align, flags); } </del> <ins> let (a_scalar, b_scalar) = match dest.layout.abi { layout::Abi::ScalarPair(ref a, ref b) => (a, b), _ => bug!("store_with_flags: invalid ScalarPair layout: {:#?}", dest.layout) }; let b_offset = a_scalar.value.size(bx).align_to(b_scalar.value.align(bx).abi); let llptr = bx.struct_gep(dest.llval, 0); let val = base::from_immediate(bx, a); let align = dest.align; bx.store_with_flags(val, llptr, align, flags); let llptr = bx.struct_gep(dest.llval, 1); let val = base::from_immediate(bx, b); let align = dest.align.restrict_for_offset(b_offset); bx.store_with_flags(val, llptr, align, flags); </ins> } } }
Code change:
reduced from num_cpus: built with yields cc `
What’s the target? Ah, never mind, I missed that its .
More minimal: Issue does not occur on stable (or 1.30.0 nightly), but occurs on rustc beta.
Marking T-libs as that is likely to be an issue within implementation of , but I didn’t investigate further.
Excerpt: Clearly both of those adjacent i32 aren't going to be 8-byte aligned ^^ It seems that we're storing to an key with wrong alignment for some reason.
Don't need to look particularly far, this code generates It looks like some code is assuming that both elements in a scalar pair have the same alignment as the whole pair.
Probably the easiest way to get to the root cause is to bisect.
This code is very likely the culprit: It takes the 0 and 1 GEPs, but uses the same alignment, without offset adjustment.
Ouch, that's bad. To obtain the alignment for both fields, we need to do: Note that we can't use because the components do not match fields (the latter come from the user type definitions, whereas the former are extracted as an optimization).

Related discussion:
text: <ins> // compile-flags: -C no-prepopulate-passes #![crate_type="rlib"] #[allow(dead_code)] pub struct Foo<T> { foo: u64, bar: T, } // The store writing to bar.1 should have alignment 4. Not checking // other stores here, as the alignment will be platform-dependent. // CHECK: store i32 [[TMP1:%.+]], i32* [[TMP2:%.+]], align 4 #[no_mangle] pub fn test(x: (i32, i32)) -> Foo<(i32, i32)> { Foo { foo: 0, bar: x } } </ins>
Code change:
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.

Related discussion:
text: println!("cargo:rustc-link-lib=advapi32"); println!("cargo:rustc-link-lib=ws2_32"); println!("cargo:rustc-link-lib=userenv"); <del> println!("cargo:rustc-link-lib=shell32"); </del> } else if target.contains("fuchsia") { println!("cargo:rustc-link-lib=zircon"); println!("cargo:rustc-link-lib=fdio");
Code change:
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.

Related discussion:
text: #![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) { }
Code change:
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.

Related discussion:
text: impl<'a> fmt::Debug for ArgsInnerDebug<'a> { fn fmt(&self, f: &mut fmt::Formatter) -> fmt::Result { <del> f.write_str("[")?; let mut first = true; for i in self.args.range.clone() { if !first { f.write_str(", ")?; } first = false; // Here we do allocation which could be avoided. fmt::Debug::fmt(&unsafe { os_string_from_ptr(*self.args.cur.offset(i)) }, f)?; } f.write_str("]")?; Ok(()) </del> <ins> self.args.parsed_args_list.as_slice().fmt(f) </ins> } }
Code change:
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.

Related discussion:
text: pub fn SetLastError(dwErrCode: DWORD); pub fn GetCommandLineW() -> *mut LPCWSTR; <del> pub fn LocalFree(ptr: *mut c_void); pub fn CommandLineToArgvW(lpCmdLine: *mut LPCWSTR, pNumArgs: *mut c_int) -> *mut *mut u16; </del> pub fn GetTempPathW(nBufferLength: DWORD, lpBuffer: LPCWSTR) -> DWORD; pub fn OpenProcessToken(ProcessHandle: HANDLE,
Code change:
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.

Related discussion:
text: # Extra flags needed to compile a working executable with the standard library ifdef IS_WINDOWS ifdef IS_MSVC <del> EXTRACFLAGS := ws2_32.lib userenv.lib shell32.lib advapi32.lib </del> <ins> EXTRACFLAGS := ws2_32.lib userenv.lib advapi32.lib </ins> else EXTRACFLAGS := -lws2_32 -luserenv endif
Code change:
The following commands no longer seem to work: With incoming, I just get check-stage2-doc-tutorial'. Stop.` and so on.
Note: the pull request I just filed fixes the targets, but the manual target is , not as you've written in the bug here. I think if the latter used to work, it's stopped working as-intended. The document name is after all.
I got the names from
Sorry, that was fallout from reorganization of
adjusted wiki page

Related discussion:
text: perf  debuginfo  doc  <del> $(foreach docname,$(DOC_TEST_NAMES),$(docname))  </del> <ins> $(foreach docname,$(DOC_TEST_NAMES),doc-$(docname))  </ins> pretty  pretty-rpass  pretty-rpass-full
Code change:
The following buggy code: produces the error: This is usefully documented in TRPL (ch08-02-strings), but that is not easily discoverable from the error. Meanwhile, the error itself is a natural one that programmers from many languages (C, C++, etc) might run into. Speaking as someone who spent some time assuming that the issue was related to slices/references/usize (i.e. various new, Rust-specific concepts), not strings and UTF-8 encoding, I wonder whether a special case might be produced, replacing error E0277, when the types involved are specifically strings/strs and integers. :
We should add a pointing to in the following code of E0277 errors. The example has a similar case to this one, but the additional code should be something along the lines of This will cause an extra to be displayed for this case. Beyond changing the code, you will also need to add a new test case with the repro case above and (running and possibly updating the test comments for any remaining failing tests).
I would like to work on this.
do not hesitate to reach out either here or on if you need help!
Possible proposed output from :

Related discussion:
text: /// ``` #[lang = "index"] #[rustc_on_unimplemented( <ins> on( _Self="&str", note="you can use `.chars().nth()` or `.bytes().nth()` see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings>" ), on( _Self="str", note="you can use `.chars().nth()` or `.bytes().nth()` see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings>" ), on( _Self="std::string::String", note="you can use `.chars().nth()` or `.bytes().nth()` see chapter in The Book <https://doc.rust-lang.org/book/ch08-02-strings.html#indexing-into-strings>" ), </ins> message="the type `{Self}` cannot be indexed by `{Idx}`", label="`{Self}` cannot be indexed by `{Idx}`", )]