jiebi/CodeConvo huggingface dataset:
Change:
b_def_id: ast::DefId) -> bool { <ins> debug!("overlap(a_def_id={}, b_def_id={})", a_def_id.repr(selcx.tcx()), b_def_id.repr(selcx.tcx())); </ins> let (a_trait_ref, a_obligations) = impl_trait_ref_and_oblig(selcx, a_def_id); let (b_trait_ref, b_obligations) = impl_trait_ref_and_oblig(selcx, b_def_id); <ins> debug!("overlap: a_trait_ref={}", a_trait_ref.repr(selcx.tcx())); debug!("overlap: b_trait_ref={}", b_trait_ref.repr(selcx.tcx())); </ins> // Does `a <: b` hold? If not, no overlap. if let Err(_) = infer::mk_sub_poly_trait_refs(selcx.infcx(), true,

Discussion:
Attempting to compile with and yields the following ICE:
Reduced test case: Still ICEs with The ICE goes away if the on the is changed to a bare instead of a reference.
Slightly different test case: EDIT: Nevermind, it's the same but uses a closure instead of the more general .
I have bisected this issue to rust-lang/rust (from )
A workaround would be simply:
This doesn't help much if you need to call methods that are on the trait (which was on the original code).
cc me
This is blocking collect-rs from compiling.
This is interesting. The culprit is : it registers obligations from implementation's methods into an hybrid parameter environment which has trait's methods in it. In the example given in this issue, when the associate type is projected out, the implementation's method acquires an extra lifetime variable. The trait's method doesn't have it so the lifetime resolution fails in an ICE later on. I'm not sure how to fix that though.
This compiles so at first glance it looks like a viable workaround: But if one tries to really use as an , compiler panics on an assertion failure:
Getting this with some hashing code.

will output something along the lines of: Start hash BYTES: [69, 84, 87, 87, 100, 57, 118, 102, 80, 97, 122, 56, 100, 116, 80, 82, 74, 78, 104, 116, 109, 51, 88, 54, 56, 98, 56, 97, 66, 119, 105, 116, 90, 114, 50, 83, 107, 99, 51, 52, 89, 121, 121, 112, 86, 116, 57, 66, 120, 87, 86, 112, 88, 55, 66, 49, 76, 90, 86, 48, 49, 53, 56, 53, 52, 48, 56, 56, 49, 53, 54, 48, 51] lyra2 finished: CfV9jehQVXsVnx6Vrg5f9VgHVkWeatbrFGxKVz2knfEc Starting argon thread 'certificate::tests::checkcertdiff' panicked at 'index out of bounds: the len is 0 but the index is 31',
Change:
rb.update_submodules() # Fetch/build the bootstrap <del> rb.build = rb.build_triple() </del> <ins> rb.build = args.build or rb.build_triple() </ins> rb.download_stage0() sys.stdout.flush() rb.build_bootstrap()

Discussion:
I tried to build a different ABI/triplet than the one rustbuild automatically guesses by using the command line option. As suggested in , But it didn't work and failed with: Setting "build" in works correctly. The script is responsible for downloading the stage0 compiler and building bootstrap (rustbuild), but it only checks which stage0 to download and use in It doesn't look at the command line at all for deciding this, which I think is the cause for this. See: .
Change:
("e", Some(sym::riscv_target_feature)), ("f", Some(sym::riscv_target_feature)), ("m", Some(sym::riscv_target_feature)), <ins> ("relax", Some(sym::riscv_target_feature)), </ins> ("v", Some(sym::riscv_target_feature)), ("zba", Some(sym::riscv_target_feature)), ("zbb", Some(sym::riscv_target_feature)),

Discussion:
I would like to enable linker relaxation for the RISC-V target. To do so I passed to tell LLVM to use linker relaxation. It seems like is not aware of this option, so it emits a warning (but the feature is still properly enabled). I can't find any way to disable this warning, so I am submitting this issue in the hopes that either the feature will become recognized, or a way to disable the warning will be . Related: . The program is compiled by running Hopefully I've posted this to the correct place. Thanks! No response No response
Does work in this context?
I tried it out and it does not seem to enable linker relaxation unfortunately.
I wonder where could I add ? Now I am using cargo build:
Why is a target feature being used for linker relaxation...?
This optimization/feature is specific to RISC-V. For the RISC-V target by default LLVM does not emit relocations (in the generated object file) for global variable lookups that tell the linker to make use of linker relaxation (generating addresses for globals using the register). I’m not sure of the rationale behind this (gcc enables it by default and uses to disable it). One reason might be that using linker relaxation does require the runtime or something to set up the register beforehand. In any case it should be possible to enable with Rust without getting a warning, and perhaps should even be enabled by default for RISC-V targets.
As mentioned in the other issue, the warning is in large part because LLVM and Rust don't always agree on the definition of a target feature, in part because LLVM has proven surprisingly willing to change the definitions. Proooobably we should just enable this by default, then, if gcc does? Hmm.
Change:
cfg.file("../rustllvm/PassWrapper.cpp") .file("../rustllvm/RustWrapper.cpp") .file("../rustllvm/ArchiveWrapper.cpp") <ins> .file("../rustllvm/Linker.cpp") </ins> .cpp(true) .cpp_link_stdlib(None) // we handle this below .compile("rustllvm");

Discussion:
I noticed my project took noticeably longer to build with "lto=true" at some point. I benchmarked link time (touch ; cargo build --release) which appear to blow up as soon as we have several codegen units. link times: So it seem codegen-units=1 makes for bad parallelism while building but speeds up lto because less translation units need to be merged. Maybe it is possible to dynamically use as little codegen units as possible (but still enough to utilize all cores) when building? //cc
Or maybe just don't use multiple codegen units by default when monolithic LTO is enabled.
I think the optimal "balance" for linktime/buildtime with monolithic lto would be to 1) compile all crates with codgen-units=1 as long as we can compile several crates in parallel. 2) if we have to compile a single crate at a time, use ${thread_number} codegen units. However this will probably introduce indeterministic builds depending on the number of threads a host machine has. So a single core machine would optimize better than a 8 core machine when building the same crate with monolithic lto. :/
I made some benchmarks (cpu: i5-2540M dual core), rustc 1.25.0-nightly ( 2018-02-11) `
I believe this is fixed in
er, didn't mean to close yet
Change:
use rustc_middle::ty::{self, InstanceKind, Ty, TyCtxt, TypeVisitableExt}; use rustc_target::abi::{FieldIdx, VariantIdx}; <ins> use crate::pass_manager::validate_body; </ins> pub struct ByMoveBody; impl<'tcx> MirPass<'tcx> for ByMoveBody {

Discussion:
<!-- [31mICE[0m: Rustc '-Zvalidate-mir --edition=2018 -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'broken MIR in CoroutineKindShim { coroutinedefid: DefId(0:8 ~ a[8079]::hello::{closure}::{closure}) } (after pass CheckPackedRef) at bb0[2]:'', 'thread 'rustc' panicked at 'broken MIR in CoroutineKindShim { coroutinedefid: DefId(0:8 ~ a[8079]::hello::{closure}::{closure}) } (after pass CheckPackedRef) at bb0[2]:'' File: --auto-reduced (treereduce-rust): original: Version information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [mirbuilt] building MIR for [checkunsafety] unsafety-checking -- label +F-async_closure
nightly-2024-05-23 =
With this full minimization: The real blame commit is:
Change:
<ins> // This test ensures that codeblocks content don't overflow. goto: file://|DOC_PATH|/lib2/sub_mod/struct.Foo.html size: (1080, 600) // There should be two codeblocks: a rust one and a non-rust one. assert-count: (".docblock > .example-wrap", 2) assert: ".docblock > .example-wrap > .language-txt" assert: ".docblock > .example-wrap > .rust-example-rendered" assert-css: (".docblock > .example-wrap > pre", {"width": "796px", "overflow-x": "auto"}, ALL) </ins>

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --Repro: text /// aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa /// rust /// bbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbbb /// Rustdoc output: ! It seems that only code block with language are affected. cc
A quick test showed that the bug was introduced in (i.e.: works fine)
label +regression-from-stable-to-nightly
Thanks, I'll fix it in the next hours.
In case you want to take a look to the fix, it's .
Change:
<del> error[E0310]: the parameter type `T` may not live long enough </del> <ins> error: `impl` associated type signature for `A` doesn't match `trait` associated type signature </ins> --> $DIR/impl_bounds.rs:15:5 | <ins> LL |     type A<'a> where Self: 'a; |     -------------------------- expected ... </ins> LL |     type A<'a> where Self: 'static = (&'a ()); <del> |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | = help: consider adding an explicit lifetime bound `T: 'static`... = note: ...so that the definition in impl matches the definition from the trait </del> <ins> |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ found </ins> error: `impl` associated type signature for `B` doesn't match `trait` associated type signature --> $DIR/impl_bounds.rs:17:5

Discussion:
<!-- Thank you for filing a bug report! Please provide a short summary of the bug, along with any information you feel relevant to replicating the bug. --I tried this code I expected to see this happen: A slightly better error message Instead, this happened: A slightly confusing error message <!-- 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<summaryBacktrace</summary<p</p</details
Change:
not(bootstrap), doc(cfg_hide( not(test), <ins> any(not(feature = "miri-test-libstd"), test, doctest), </ins> target_pointer_width = "16", target_pointer_width = "32", target_pointer_width = "64",

Discussion:
shows this annotation: This doesn't seem very useful for an end-user, and this annotation shows for every page in the documentation. This issue also affects crate.
the fix is to add to the crate root; it would be a good first PR :)
Change:
ENV TARGETS=$TARGETS,armv7r-none-eabihf ENV TARGETS=$TARGETS,thumbv7neon-unknown-linux-gnueabihf <ins> # riscv targets currently do not need a C compiler, as compiler_builtins # doesn't currently have it enabled, and the riscv gcc compiler is not # installed. </ins> ENV CC_mipsel_unknown_linux_musl=mipsel-openwrt-linux-gcc  CC_mips_unknown_linux_musl=mips-openwrt-linux-gcc  CC_mips64el_unknown_linux_muslabi64=mips64el-linux-gnuabi64-gcc 

Discussion:
Do we have plan to get rid of this restriction recently? A newer version of cc-rs is needed for VxWorks
can't currently be updated due to a build problem with riscv. More info at I think the issue is that rustbuild uses cc to discover cc toolchains, and gained riscv support, and so now it thinks it should use a gcc toolchain that doesn't exist. The detection is in and Alex mentioned just setting a env var in the riscv container might be enough. It's been on my todo list for a while, but I haven't had a chance to look at it. I can maybe try to look at it this weekend.
Thanks for working on this issue. Enjoy your weekend, it is not that urgent.
Change:
extern { pub type ModuleBuffer; } extern "C" { <ins> pub fn LLVMRustInstallFatalErrorHandler(); </ins> // Create and destroy contexts. pub fn LLVMRustContextCreate(shouldDiscardNames: bool) -> &'static mut Context; pub fn LLVMContextDispose(C: &'static mut Context);

Discussion:
Related to . If a fatal error occurs in LLVM, the compiler exits with status 1. This is problematic, because if a test is expecting a compilation failure, the test could still pass. It also makes it difficult to test for the presence of ICEs in general. A simple fix would be to patch our copy of LLVM to exit with 101 (like ICEs) in , but any other ideas would be appreciated.
Those error functions all call , which sounds like it could be a great hook for us, but then that only calls . :/
There is  though, and that handler gets called first.
That sounds nice, but if we exit with 101 (or simply panic) in the handler won't we be skipping any other cleanup (, plus any future cleanup that gets there)? Or could we just call it in our handler? I'm interested in putting a patch together, but I'm unfamiliar with how we link Rust to C++. The error handler needs to be able to consume a .
We shouldn't do anything that looks like exception unwinding. See : I think we can call it -- it's publicly declared in . We might want to keep a note to make sure we check for new cleanup needed when we update LLVM though. We bridge C++ code in . You could just write our handler in C++ there, and add some C-FFI function for to call and hook that up.
Change:
<ins> #![feature(type_ascription)] enum Bug<S> { Var = 0: S, //~^ ERROR: mismatched types //~| ERROR: mismatched types } fn main() {} </ins>

Discussion:
Given this Rust code: A call to generates IR like this on x86_64 Linux: So we have a 12 byte alloca from which we then read 16 bytes.
Isn't this subject to alignment by LLVM?
what do you mean? The alloca is only 12 bytes large. That's also the amount of bytes we write in the , but then we ask to read data for a type that is 16 bytes large. I don't see how alignment is relevant here.
here's a demo: Build without optimizations on x86_64 Linux, and you should be able to observe in the C code, although it hasn't been passed as an argument. The mismatch in the struct type definitions is deliberate to show the problem.
Reading past the end of an alloca has well-defined behavior in LLVM IR. I guess we might end up with false positives if we ever support msan.
are you implying that the generated IR is fine? If so, what is the defined behaviour / where can I read up on that? reads as if it is undefined. Without optimizations, this gives random output: With optimizations, SROA ignores the out-of-bounds read and emits a warning in debug mode, which doesn't seem like it is well-defined behaviour to me either.
Basically, if a pointer points to valid memory, and is sufficiently aligned, you can load bytes up to the alignment... LLVM itself does this at etc. That said, looking a bit more closely, the given testcase performs an "align 8" load from an "align 4" pointer, which is more problematic.
Thanks! That looks like it just assumes that the load won't trap. Part of my concern here is that we might expose additional data this way, like observing in that C code example. Though I guess optimizations might eventually leave the upper 32bits undefined and expose data anyway, so this might be moot. The alignment problem is probably due to bad usage of . Ultimately, we should load and pass the struct elements individually anyway.
This has been fixed, we now only load 12 bytes: instead of . Marking as E-needstest.
Change:
self.props.compare_output_lines_by_subset, ); } else if !expected_fixed.is_empty() { <del> panic!( "the `// run-rustfix` directive wasn't found but a `*.fixed`  file was found" ); </del> <ins> if self.config.suite == "ui" { panic!( "the `//@ run-rustfix` directive wasn't found but a `*.fixed` file was found" ); } else { panic!( "the `// run-rustfix` directive wasn't found but a `*.fixed` file was found" ); } </ins> } if errors > 0 {

Discussion:
No response The lint is marked able but applying the suggestion fails: ` No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Same problem with
claim
I think this is a known issue with with applying all suggestions even if they are multually exclusive. I'm pretty sure there's nothing to do in the lint, it correctly suggests the two (valid) suggestions, only one of them should be applied.
Well we can either remove one of the suggestions or make the lint MaybeIncorrect or something?
I think this is We can't remove one of the suggestions, they are both necessary. We can however make them for the time being.
That is indeed unfortunate.
Change:
cvt_nz(libc::posix_spawnattr_setflags(attrs.0.as_mut_ptr(), flags as _))?; // Make sure we synchronize access to the global `environ` resource <del> let _env_lock = sys::os::env_read_lock(); </del> <ins> let _env_lock = sys::os::env_lock(); </ins> let envp = envp.map(|c| c.as_ptr()).unwrap_or_else(|| *sys::os::environ() as *const _); cvt_nz(libc::posix_spawnp( &mut p.pid,

Discussion:
For example: i686-gnu, i686-gnu, i686-gnu-nopt, i686-gnu-nopt, i686-gnu, i686-gnu-nopt, i686-gnu, i686-gnu-nopt i686-gnu, i686-gnu, i686-gnu, x8664-gnu-distcheck, i686-gnu-nopt, x8664-gnu-tools, i686-gnu, i686-gnu-nopt, i686-gnu-nopt,
Posted a fix at .
Change:
// We can still be zero-sized in this branch, in which case we have to // return `None`. <del> if size.bytes() == 0 { None } else { Some(ptr) } </del> <ins> if size.bytes() == 0 { // We may be reading from a static. // In order to ensure that `static FOO: Type = FOO;` causes a cycle error // instead of magically pulling *any* ZST value from the ether, we need to // actually access the referenced allocation. The caller is likely // to short-circuit on `None`, so we trigger the access here to // make sure it happens. self.get_raw(ptr.alloc_id)?; None } else { Some(ptr) } </ins> } }) }

Discussion:
I tried this code: I expected the code to fail to compile with a cycle error. Instead, it compiled and ran,printing the value of . I was able to verify that this bug happens for the 1.42.0 stable, 1.43-beta.5, and 1.44.0-nightly(2020-04-11 ) versions. Trying this code in it errors up to 1.36.0,and doesn't error anymore from 1.37.0 onwards.
cc
narrowed to the following: Auto merge of - petrochenkov:builtout, r=eddyb Auto merge of - luca-barbieri:optimize-refcell-borrow, r=RalfJung Auto merge of - Centril:rollup-, r=Centril Auto merge of - petrochenkov:rpass, r=Centril Possibly ?
Weaponized soundness hole (using as a foundation): ==
cc
oopsie yeah... is probably where this started. But that is crucial to fix The problem is that "reading from a ZST" isn't actually doing anything. Here's the MIR for : So there actually is a that loads from this static (I didn't expect that). But in Miri, a ZST load just checks that the address is in-bounds; no actual access to the underlying memory happens so there is no cycle error.
Assigning as and removing .
Change:
<ins> // compile-flags: --crate-type=lib -Cdebuginfo=2 // build-pass #![feature(type_alias_impl_trait)] type Debuggable = impl core::fmt::Debug; static mut TEST: Option<Debuggable> = None; fn foo() -> Debuggable { 0u32 } </ins>

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
cc
Change:
<ins> error[E0275]: overflow evaluating the requirement `fn() -> Foo {foo}: Sized` --> $DIR/issue-53398-cyclic-types.rs:6:5 | LL |     foo |     ^^^ | = help: consider increasing the recursion limit by adding a `#![recursion_limit = "256"]` attribute to your crate (`issue_53398_cyclic_types`) error: aborting due to previous error For more information about this error, try `rustc --explain E0275`. </ins>

Discussion:
Possibly related to as both ICEs arise from , but this ICE occurs on a different line. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
No longer ICEs since

I tried this code: I expected to see this happen: code compiles successfully Instead, this happened: : : modify labels: +requires-nightly +F-typealiasimpl_trait
This is fixed now

I'm writing a simple Generator that takes a reference to an RNG, and yields values from it. This makes sense as long as the generator doesn't outlive the RNG which it references. I want to name the type of the generator with an existential type, but I can't do so unless I wrap a version of the function that uses an formulation. Here's the direct version which doesn't work and here's the more convoluted version which does and here's a playground link containing both versions, as well as a bit of scaffolding The full error message I'm seeing looks like this
I don't know if this properly counts as a compiler bug, but it feels like one because the "fix" is a very mechanical code transformation.
cc
Yea that's definitely a bug. I'll investigate where this unnamed lifetime is coming from. Maybe I'm accidentally erasing lifetimes somewhere
This is fixed in master. A more minimal example that probably still failed previously (needs to be checked) that doesn't depend on or never type:

I assumed that the following code would be legal, as it does not require indefinitely sized types, but apparently somewhere the existential type is revealed too early: () Errors:
Updated version: This still doesn't compile.
Using min-type-alias-impl-trait (), you get an error. I think this is ok, though, as it is we don't support cyclic types like this. I'm going to mark this as E-needs-test.
If we adopted a different model of impl trait, one where they were more "nominal" and hence could be cyclic, that'd be a different thing.
Change:
dest) } ast::ExprTup(ref args) => { <del> let repr = adt::represent_type(bcx.ccx(), expr_ty(bcx, expr)); </del> let numbered_fields: Vec<(uint, Gc<ast::Expr>)> = args.iter().enumerate().map(|(i, arg)| (i, *arg)).collect(); <del> trans_adt(bcx, &*repr, 0, numbered_fields.as_slice(), None, dest) </del> <ins> trans_adt(bcx, expr_ty(bcx, expr), 0, numbered_fields.as_slice(), None, dest) </ins> } ast::ExprLit(lit) => { match lit.node {

Discussion:
The current translation for struct update in the case of ignore looks incorrect. It should only move those fields that are not specified manually. This can mean the difference between moving the base as a whole and not. Probably the easiest thing to do is to create an alloca, use the same code as the normal path, and just drop the alloca afterwards.
See FIXME.
visiting for triage. nominating for production ready.
Accepted for production-ready
visting for triage, still relevant. FYI, the module in question is