jiebi/CodeConvo huggingface dataset:
Change:
cx.vtables().borrow_mut().insert((ty, trait_ref), vtable); vtable } <ins> /// Call this function whenever you need to load a vtable. pub(crate) fn load_vtable<'a, 'tcx, Bx: BuilderMethods<'a, 'tcx>>( bx: &mut Bx, llvtable: Bx::Value, llty: Bx::Type, vtable_byte_offset: u64, ty: Ty<'tcx>, nonnull: bool, ) -> Bx::Value { let ptr_align = bx.data_layout().pointer_align.abi; if bx.cx().sess().opts.unstable_opts.virtual_function_elimination && bx.cx().sess().lto() == Lto::Fat { if let Some(trait_ref) = dyn_trait_in_self(ty) { let typeid = bx.typeid_metadata(typeid_for_trait_ref(bx.tcx(), trait_ref)).unwrap(); let func = bx.type_checked_load(llvtable, vtable_byte_offset, typeid); return func; } else if nonnull { bug!("load nonnull value from a vtable without a principal trait") } } let gep = bx.inbounds_ptradd(llvtable, bx.const_usize(vtable_byte_offset)); let ptr = bx.load(llty, gep, ptr_align); // VTable loads are invariant. bx.set_invariant_load(ptr); if nonnull { bx.nonnull_metadata(ptr); } ptr } </ins>

Discussion:
<!-- [31mICE[0m: Rustc ./subtyping-impacts-selection-2.rs '-Zvirtual-function-elimination=true -Clto=true -ooutputfile -Zdump-mir-dir=dir' 'thread 'rustc' panicked at 'expected principal trait object'', 'thread 'rustc' panicked at 'expected principal trait object'' File: /tmp/im/subtyping-impacts-selection-2.rs --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: --
Seems to be a duplicate of
Regression in nightly-2022-06-16 commit[0] 2022-06-14: Auto merge of - b-naber:transition-to-valtrees-in-type-system, r=lcnr commit[1] 2022-06-14: Auto merge of - flip1995:pk-vfe, r=nagisa commit[2] 2022-06-15: Auto merge of - compiler-errors:if-cond-and-block, r=oli-obk commit[3] 2022-06-15: Auto merge of - JohnTitor:rollup-rfg1a4s, r=JohnTitor commit[4] 2022-06-15: Auto merge of - nnethercote:rm-thread-local-IGNORED_ATTRIBUTES, r=michaelwoerister commit[5] 2022-06-15: Auto merge of - JohnTitor:rollup-c17vjdy, r=JohnTitor commit[6] 2022-06-15: Auto merge of - AzureMarker:feature/horizon-std, r=nagisa commit[7] 2022-06-15: Auto merge of - c410-f3r:assert-compiler, r=oli-obk commit[8] 2022-06-15: Auto merge of - sunfishcode:ownedfd-and-dup, r=joshtriplett looks like this has been broken eversince

This happens when compiling the crate with . : The backtrace and output here are obtained during cross-compilation (host , target , build-std), but the panic also happens when the host is Windows and without build-std. <details<summary<strongBacktrace</strong</summary<p</p</details
Minimized:
Change:
LL | #![deny(unreachable_code)] |         ^^^^^^^^^^^^^^^^ <del> error: unreachable expression --> $DIR/expr_method.rs:21:5 </del> <ins> error: unreachable call --> $DIR/expr_method.rs:21:9 </ins> | LL |     Foo.bar(return); <del> |     ^^^^^^^^^^^^^^^ </del> <ins> |         ^^^ </ins> error: aborting due to 2 previous errors

Discussion:
rustc warns that the entire line is an unreachable expression however the code is clearly executed as can be see If the line was truly unreachable, there would be no panic... This bug appears on stable, beta and nightly
The is the unreachable part, so perhaps the error should be rephrased and pointed at that function call only
Hmm, so the span is wrong?
the order of execution is panic! and then everything else, so in some sense everything but the panic is unreachable. I'm not sure what a good span for that would be.
The method receiver is evaluated first, so the and calls still happen. The span can point just at the .
Ah, hm, I didn't expect that to be the case, but it makes sense. Then this seems relatively straightforward as to what the expected output is at least.
I feel like this should also add a note that the panic is called before everything else. It could also suggest but that seems more like a clippy lint.
Similar case: Maybe we can simply add a note that won't be called because evaluation of its arguments leaves the current code path. I agree that suggestion is indeed too specific and may be better suited to clippy. If this is acceptable, I would like to pick it up! As long as it's fine for me to progress more slowly than normal
GitHub wasn't clever enough to read that the PR said "might close" instead of "close." The PR seems to imply more work can be done on this.
Change:
<ins> #![feature(const_let)] const FOO: *const u32 = { //~ ERROR any use of this value will cause an error let x = 42; &x }; fn main() { let x = FOO; } </ins>

Discussion:
Spawned off of 's on :
to be clear: we don't need to use to reproduce the problem, right? I.e. hypothetically examples exist that don't use that feature? In particular I know this problem is in some way related to , which is definitely a true regression of stable code.
Right, this here is not really a regression. It is just an ICE that should be an error and it is fixed by We can probably do this without const_let, but I couldn't come up with an example.
A user is the
I have tried to reduce the problem. This repository is smaller, but still fails on : . The same crate builds on stable.
I think you are encountering which has a fix in (making everything work again) This issue is different, even though the symptom is the same right now. When this issue is fixed (via ), the ICE will become a hard error.
Change:
help: the bound will not be checked when the type alias is used, and should be removed | LL | type SVec<T> = Vec<T>; <del> |     --    -- </del> <ins> |           -- </ins> warning: where clauses are not enforced in type aliases --> $DIR/type-alias-bounds.rs:10:21

Discussion:
Hi, i have made some changes for a crate to support a generic type that implements from , but suddenly the code can't compile because it runs out of memory with 6, 8, 10 GB. This is the code i'm trying to compile: if changed the type for or it then compiles and runs fine. Source: It fails to compile on x86_64-unknown-linux-gnu with , . I'm attaching the Heaptrack files for further analysis.
It seems a problem with utilized in the , unfortunately memory report is strange, the execution time tracked is wrong besides the graph shows up the memory grow. I'm thinking ways to better troubleshoot, but the side effects of the issue is hard.
It'd be helpful to try and simplify the code, ideally to something that doesn't have dependencies (beyond std or so), or at least as few dependencies as possible. As a start putting up a github repository with a and as simple a crate as possible would be helpful for reproducing on our side (i.e., extracting the file you've linked from that crate -- or, if the crate is really necessary, then indicating as such). The heaptrack profile looks pretty useless unfortunately -- rustc on linux is shipped with jemalloc as the allocator which likely makes heaptrack tracking not really work too well.
Thank you, sorry for the late response (working) but i get it working on playground. I'm now trying to minimize them to focus on the issue.
Got it down to 18 lines. Still produces the same error. I have not tested if this goes out-of-memory. But receiving a would signal that. EDIT: After taking some more time, I got rid of Tokio and reduced it to 6 lines: Additionally, I advise to rename this issue to something like to make it very clear and concise.
One liner: . Strangely, this no longer crashes if you remove any of , , , or .

There's nothing special about Send or Sync, this also crashes: Even weirder, this does not crash: (I didn't come up with the one-liner, that was
I stopped rustc (SIGSTOP) and got a backtrace with gdb, it looks like it's trying to generate infinite errors: <details<summarybacktrace</summary</details
It looks like this is a problem with the error reporter itself: it's affected by the length of the name (!!) OOM: No OOM:
I figured out the issue has to do with how the error printer places the annotations, adding a newline after the trait names and before the plus solves the issue.
Probably caused by some code in here:
Change:
<ins> // Checks that the following does not ICE when constructing type mismatch diagnostic involving // `Self` and const generics. // Issue: <https://github.com/rust-lang/rust/issues/122467> pub struct GenericStruct<const N: usize, T> { thing: T, } impl<T> GenericStruct<0, T> { pub fn new(thing: T) -> GenericStruct<1, T> { Self { thing } //~^ ERROR mismatched types } } pub struct GenericStruct2<const M: usize, T>(T); impl<T> GenericStruct2<0, T> { pub fn new(thing: T) -> GenericStruct2<1, T> { Self { 0: thing } //~^ ERROR mismatched types } } fn main() {} </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. --Strangely enough, the following does not ICE: <!-- 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. --: Also occured on nightly However, it appeared to not happen on rustc stable 1.75.0 <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I'm pretty sure this is from , cc
I would also like to add this also causes an ICE, so it's likely that it has to do with type constructors
Change:
); fn is_expr_delims_necessary(inner: &ast::Expr, followed_by_block: bool) -> bool { <del> followed_by_block && match inner.kind { ExprKind::Ret(_) | ExprKind::Break(..) => true, _ => parser::contains_exterior_struct_lit(&inner), </del> <ins> // Prevent false-positives in cases like `fn x() -> u8 { ({ 0 } + 1) }` let lhs_needs_parens = { let mut innermost = inner; loop { if let ExprKind::Binary(_, lhs, _rhs) = &innermost.kind { innermost = lhs; if !rustc_ast::util::classify::expr_requires_semi_to_be_stmt(innermost) { break true; } } else { break false; } </ins> } <ins> }; lhs_needs_parens || (followed_by_block && match inner.kind { ExprKind::Ret(_) | ExprKind::Break(..) => true, _ => parser::contains_exterior_struct_lit(&inner), }) </ins> } fn emit_unused_delims_expr(

Discussion:
In this example: rustc throws a warning: Removing the parentheses as the message directs causes errors: It seems the warning is wrong, unless this is expected to compile <!-- 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. --: This also happens on nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I think this may apply to any binary op where the left-hand side is an expression that can be a statement without a semicolon, per: For example, adding with block expressions also reports unused parens: but removing those gets an error: As a workaround, it doesn't trigger if the operands are wrapped separately: or
claim
Change:
<ins> error: argument 3 is required to be a constant --> $DIR/const_arg_wrapper.rs:9:5 | LL |     _mm_clmulepi64_si128(a, b, imm8) |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ error: aborting due to previous error </ins>

Discussion:
Expected the following code to compile But getting Repro:
Also happens on beta, not on stable
Stable says:
For reference, the function signature as defined is exactly the same.
The actual ICE occurs first in nightly-2019-03-03 (...). But interesting enough, stable (as jonas pointed out) procuces an error, saying, that the third argument must be a constant. Since nightly-2019-02-16 (...) this does not emit an error anymore, but also does not ICE.
I guess for the "does not emit an error anymore" can say something about it. should be responsible for it.
triage: P-high
Note that because of the on the definition, you can't wrap it (without matching on and having 256 separate calls). I don't think this is intentional, but I'm not sure why it would happen, maybe arguments are treated incorrectly in the qualifier. cc
So I agree that this code can't compile, that's the expected behavior; if you want to wrap it, you have to use a macro - Rust functions aren't able to abstract over this type of hardware operations yet. The ICE is a regression over the error message that was being produced before. We should definitely add an ui test for that.
triage, assigning to self to fix the stable-to-beta regression.
The behavior here varies with edition as well as channel. edition 2018 ------------------ ------------------------ stable expected error beta unexpected compile-pass nightly-2019-04-05 ICE I think the most immediate thing to address is the unexpected compile-pass that has leaked into beta.
The easiest thing might be to revert
I have an actual fix in (also easier to backport than a revert)
Okay then I'm reassigning to
Change:
<ins> // https://github.com/rust-lang/rust/issues/55223 #![feature(const_let)] union Foo<'a> { y: &'a (), long_live_the_unit: &'static (), } const FOO: &() = { //~ ERROR any use of this value will cause an error let y = (); unsafe { Foo { y: &y }.long_live_the_unit } }; fn main() {} </ins>

Discussion:
Spawned off of 's on :
to be clear: we don't need to use to reproduce the problem, right? I.e. hypothetically examples exist that don't use that feature? In particular I know this problem is in some way related to , which is definitely a true regression of stable code.
Right, this here is not really a regression. It is just an ICE that should be an error and it is fixed by We can probably do this without const_let, but I couldn't come up with an example.
A user is the
I have tried to reduce the problem. This repository is smaller, but still fails on : . The same crate builds on stable.
I think you are encountering which has a fix in (making everything work again) This issue is different, even though the symptom is the same right now. When this issue is fixed (via ), the ICE will become a hard error.
Change:
// `Ty`/`Const`/`Predicate`, but not within those types. This is because the // type flags at the outer layer are enough. So it's faster than it first // looks, particular for `Ty`/`Predicate` where it's just a field access. <ins> // // N.B. The only case where this isn't totally true is binders, which also // add `HAS_{RE,TY,CT}_LATE_BOUND` flag depending on the *bound variables* that // are present, regardless of whether those bound variables are used. This // is important for anonymization of binders in `TyCtxt::erase_regions`. We // specifically detect this case in `visit_binder`. </ins> impl<'tcx> TypeVisitor<TyCtxt<'tcx>> for HasTypeFlagsVisitor { type BreakTy = FoundFlags; <ins> fn visit_binder<T: TypeVisitable<TyCtxt<'tcx>>>( &mut self, t: &Binder<'tcx, T>, ) -> ControlFlow<Self::BreakTy> { // If we're looking for any of the HAS_*_LATE_BOUND flags, we need to // additionally consider the bound vars on the binder itself, even if // the contents of a the binder (e.g. a `TraitRef`) doesn't reference // the bound vars. if self.flags.intersects(TypeFlags::HAS_LATE_BOUND) { let bound_var_flags = FlagComputation::bound_var_flags(t.bound_vars()); if bound_var_flags.flags.intersects(self.flags) { return ControlFlow::Break(FoundFlags); } } t.super_visit_with(self) } </ins> #[inline] fn visit_ty(&mut self, t: Ty<'tcx>) -> ControlFlow<Self::BreakTy> { // Note: no `super_visit_with` call.

Discussion:
: The bug seems to be present in the latest nightly at well as stable. <details<summary<strongBacktrace</strong</summary<p</p</details
It seems like this has something to do with appearing multiple times, once in 's bound, then again in 's. Switching the order of the two bounds seems to avoid the error.
Regression in nightly-2021-07-25 commit[0] 2021-07-23: Auto merge of - JohnTitor:rollup-dht22jk, r=JohnTitor commit[1] 2021-07-23: Auto merge of - JohnTitor:get-by-key-enum-part-2, r=oli-obk commit[2] 2021-07-24: Auto merge of - SparrowLii:MaybeTrait, r=wesleywiser commit[3] 2021-07-24: Auto merge of - Mark-Simulacrum:bump-version, r=Mark-Simulacrum commit[4] 2021-07-24: Auto merge of - In-line:zircon-thread-name, r=JohnTitor commit[5] 2021-07-24: Auto merge of - crlf0710:rich_vtable, r=nikomatsakis commit[6] 2021-07-24: Auto merge of - Aaron1011:inert-warn, r=petrochenkov commit[7] 2021-07-24: Auto merge of - Manishearth:rollup-b09njin, r=Manishearth commit[8] 2021-07-24: Auto merge of - BoxyUwU:cgd-subst-ice, r=nikomatsakis
Change:
) except (subprocess.CalledProcessError, OSError, RuntimeError): # see http://serverfault.com/questions/301128/how-to-download <del> if platform_is_win32: run(["PowerShell.exe", "/nologo", "-Command", </del> <ins> if platform_is_win32(): run_powershell([ </ins> "[Net.ServicePointManager]::SecurityProtocol = [Net.SecurityProtocolType]::Tls12;", "(New-Object System.Net.WebClient).DownloadFile('{}', '{}')".format(url, path)], verbose=verbose,

Discussion:
I tried this: I expected to see this happen: Bootstrap rebuilds the compiler. Instead, this happened: <!-- 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. --is
In particular, this happens when rust-analyzer is running in the background and you have this config set: We currently recommend that config in https://rustc-dev-
This would be fixed by having a "public" and "private" sysroot: https://rust-
This happens because Windows doesn't allow deleting a running executable/DLL. The way forward would be to special-case it as it is already the case with the file and ignore failures, or to make a double sysroot as you proposed.
You can usually rename a running executable so it may be possible to simulate a delete by moving it within the same filesystem. However, having a public and a private sysroot seems like a more generally useful solution.
I'm happy with both solutions. I think special casing proc-macro-server in the short term seems fine, but if we do that, we should open another issue for the public and private sysroot.
Change:
pub fn unsized_part_of_type(cx: &ctxt, ty: t) -> t { match get(ty).sty { ty_str | ty_trait(..) | ty_vec(..) => ty, <del> ty_struct(_, ref substs) => { // Exactly one of the type parameters must be unsized. for tp in substs.types.get_slice(subst::TypeSpace).iter() { if !type_is_sized(cx, *tp) { return unsized_part_of_type(cx, *tp); } } fail!("Unsized struct type with no unsized type params? {}", ty_to_string(cx, ty)); </del> <ins> ty_struct(def_id, ref substs) => { let unsized_fields: Vec<_> = struct_fields(cx, def_id, substs).iter() .map(|f| f.mt.ty).filter(|ty| !type_is_sized(cx, *ty)).collect(); // Exactly one of the fields must be unsized. assert!(unsized_fields.len() == 1) unsized_part_of_type(cx, unsized_fields[0]) </ins> } _ => { assert!(type_is_sized(cx, ty),

Discussion:
cc
This should be a compiler error, not an ICE. The error is (or should be) that is unsized, but is not a bare .
Why would this be an error? Isn't enabling this kind of code part of the goal of DST?
Not quite. We want to allow struct's last field to be potentially unsized, but it must be possible to have a sized version too. This is because only sized types can be instantiated. Since there is no possible sized version of , it cannot be instantiated and should be an error.
Hm, I see. This is kinda unfortunate though, because you can't hide away the actual slice type from your wrapper. Eg, you could do But that widens your wrapper to possibly be instantiated with more than and . Maybe allow a struct definition like but to use it you need to transmute something like ? As an aside, the example in this issue would probably not work anyway, as the stride should presumably be stored per pointer, and not once in the target matrices backing memory. But this is till relevant for newtype wrappers around , eg a hypothetical
Change:
<ins> // Copyright 2018 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. use std::ffi::OsString; fn main() { let os_str = OsString::from("Hello Rust!"); assert_eq!(os_str, "Hello Rust!"); assert_eq!("Hello Rust!", os_str); } </ins>

Discussion:
I've just got very surprised to find out that doesn't compile, but does. After some investigation, I found that is missing. Similar impl is present for though. I believe it'd be nice to implement it.
is to as is to , so check out , this implementation might meet your needs.
I've soled my problem immediately. I filed issue because I think we could help others by implementing the trait.
Change:
/// /// [`BuildHasher`]: trait.BuildHasher.html /// [`Default`]: ../default/trait.Default.html <ins> /// [method.default]: #method.default </ins> /// [`Hasher`]: trait.Hasher.html /// [`HashMap`]: ../../std/collections/struct.HashMap.html <ins> /// [`HashSet`]: ../../std/collections/struct.HashSet.html /// [zero-sized]: https://doc.rust-lang.org/nomicon/exotic-sizes.html#zero-sized-types-zsts </ins> #[stable(since = "1.7.0", feature = "build_hasher")] pub struct BuildHasherDefault<H>(marker::PhantomData<H>);

Discussion:
Part of Here's what needs to be done to close out this issue: needs a stronger summary/explanation distinction. "This structure is zero-sized and does not need construction." is weird. also needs a stronger summary/explanation distinction. It also needs a better explanation of why it exists with an example. needs general improvement, it is the main bit of this module, but its docs feel tossed together and have few examples or coherence. needs more than just a summary line; it needs explanation and examples.
What kind of further documentation are you looking for here?
Better explanations for examples of implementing and and and more docs generally for all three.
There seem to be a lengthy example of BuildHasherDefault in this commit () Also for BuildHasher and there is a healthy amount of documentation as of now. Hasher seems to be really outdated (still lists several Implementors without mentioning they have been deprecated), which I'm looking into right now.
Thanks ! Looks like all that's left is documenting .
I am happy to mentor anyone who wants to tackle this issue.
I volunteer as a tribute :-)
wonderful! If you need any help, please just let me know, as I said above, happy to help you help me (We can do it here or ping me on IRC)
I have more specifics in the main issue above
I'm gonna tackle this one this weekend! (if that's okay with you,
Change:
//!   int)` and `rec(x=int, y=int, z=int)` will have the same `llvm::Type`. use crate::back::write::{ <del> start_async_codegen, submit_codegened_module_to_llvm, submit_post_lto_module_to_llvm, submit_pre_lto_module_to_llvm, OngoingCodegen, </del> <ins> compute_per_cgu_lto_type, start_async_codegen, submit_codegened_module_to_llvm, submit_post_lto_module_to_llvm, submit_pre_lto_module_to_llvm, ComputedLtoType, OngoingCodegen, </ins> }; use crate::common::{IntPredicate, RealPredicate, TypeKind}; use crate::meth;

Discussion:
First compile is ok, after I modify some contents. It failed. I've to . Then works.
I don't know how to setup a minimal env to reproduce this. But I'd love to provide any info you needed.
cc Is this maybe related to ? (Although this sounds like the opposite of that, where it is missing the bit code.)
Some digging shows that this is a preexisting bug in rustc: I believe that this is only showing up now because Cargo is only just now passing
I've posted a fix for this at