jiebi/CodeConvo huggingface dataset:
Change:
mark_variable_as_used_mut(self, assignee_cmt); } } return; } <del> // Initializations are OK. </del> <ins> // Initializations are OK if and only if they aren't partial // reinitialization of a partially-uninitialized structure. </ins> if mode == euv::Init { return }

Discussion:
So I was curious how Drop handles cycles, because this could lead to dangling pointers, which is why . And indeed the below example does not call Drop. But is moved into , so why does this compile at all?
Nominating, seems like a soundness hole.
This is an issue with zeroing dynamic drops (which are going to be removed: rust-lang/rfcs) – when is moved, its drop flag is cleared, which prevents the destructor of from running. A clearer example is:
Structs that implement drop are not supposed to be in a partially initialized state. We already prevents moves out from individual fields, but we also need to prevent individual fields from being re-initialized. cc since (iirc?) he was working on the patches that made us more accepting around re-initializing fields and so forth, and maybe this bug is of interest to him.
So we are not supposed to allow structs that implement drop to be partially initialized. We already disallow going from fully-initialized to partially initialized. But it seems (from the first example) that we missed disallowing going from fully-uninitialized to partially initializd. That needs to be fixed. Assigning P-backcompat-lang, 1.0.
While this will hopefully be fixed soon, as there is a PR up, it seems to have fallen through the cracks as a P-backcompat-lang issue that is only on the 1.0 milestone and not 1.0 beta. Nominating for 1.0 beta. (Also, I guess I will try to run through and find any other such overlooked issues.)
Assigning 1.0 beta.
Change:
label_ribs: Vec::new(), lifetime_ribs: Vec::new(), current_trait_ref: None, <del> diagnostic_metadata: DiagnosticMetadata::default(), </del> <ins> diagnostic_metadata: Box::new(DiagnosticMetadata::default()), </ins> // errors at module scope should always be reported in_func_body: false, lifetime_uses: Default::default(),

Discussion:
We should experiment with making the field in boxed and run perf to see if that improves compilation times. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Actually, I'm not sure I understand how this (alone) could yield any improvement; is there something more to the proposed changes? As it stands, purely boxing the field will surely only add heap allocation cost?
Thanks for looking into this! It depends entirely on the access patterns. Some of the diagnostic metadata substructs we have elsewhere in the compiler are accessed very rarely, while their parent struct is moved/copied/cloned often, so moving those into the heap provides improvements due to better caching/inlining. I had a hunch that this particular case might not be too impactful, but it was worth testing (and there are a handful of cases where there seems to be benefit!).
Change:
<ins> #![feature(const_generics, const_evaluatable_checked)] #![allow(incomplete_features)] struct Bool<const B: bool>; trait True {} impl True for Bool<true> {} fn test<T, const P: usize>() where Bool<{core::mem::size_of::<T>() > 4}>: True { todo!() } fn main() { test::<2>(); //~^ ERROR wrong number of type //~| ERROR constant expression depends } </ins>

Discussion:
I got a little excited with merged, soooo I gave it a try, and I found this rather funny ICE. Notice how I call , without a type parameter, while the function expects a type parameter. <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
yeah, that ICE is interesting :thinking: and why is it only triggered with ? claim

() Errors: Probably related: Removing (at least) one of the s for makes the panic go away, and the compiler correctly reports the error: modify labels: I-ICE, T-compiler, A-const-eval, A-const-generics, C-bug, F-const_generics, requires-nightly
That's happening here: I don#t think there is a meaningful way to evaluate a polymorphic constant, so either some code earlier screwed up to even get so far, or we need to throw here. Cc
cc This ICE is totally expected. Using features that emit the lint are expected to ICE, otherwise they would not emit said lint. The const evaluator is not at fault here, there's just no way to evaluate this.
hmm, we shouldn't try to evaluate this constant here or at least have it be a instead of a . Not quite sure what's going on here, will have to look at it in more detail soon
So we probably fail here because we call with a which get's canonicalized to a . All of that seems correct to me :thinking: Is it possible that we should treat similar to and "just" return here?

<!-- 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. --Code from glacier: <!-- 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
NB: Only panics for me with the flag.
Change:
LL |     let val = v as isize; |               ^^^^^^^^^^ help: consider using the `From` trait instead: `isize::from(v)` | <del> = note: an `as` expression can only be used to convert between primitive types or to coerce to a specific trait object </del> <ins> = note: an `as` expression can be used to convert enum types to numeric types only if the enum type is unit-only or field-less = note: see https://doc.rust-lang.org/reference/items/enumerations.html#casting for more information </ins> error: aborting due to 1 previous error

Discussion:
Possibly link to the Rust Reference where this is explained in detail. Casting an enum to an int is common for C developers. When I searched the internet for guides on how to do this in Rust, they all essentially said it just works like . E.g. , . These guides don't explicitly say that this only works if all of the enum variants are unit-like. The compiler message in this situation did not help me to understand what had gone wrong, and googling for it and "enum" returned the same sort of results as mentioned above. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label D-newcomer-roadblock D-confusing
claim
Change:
self.handle_field_pattern_match(pat, fields.as_slice()); } _ if pat_util::pat_is_const(def_map, pat) => { <del> // it might be the only use of a static: </del> <ins> // it might be the only use of a const </ins> self.lookup_and_handle_definition(&pat.id) } _ => () } <del> self.ignore_paths = true; </del> <ins> self.ignore_non_const_paths = true; </ins> visit::walk_pat(self, pat); <del> self.ignore_paths = false; </del> <ins> self.ignore_non_const_paths = false; </ins> } fn visit_path(&mut self, path: &ast::Path, id: ast::NodeId) { <del> if !self.ignore_paths { self.lookup_and_handle_definition(&id); } </del> <ins> self.lookup_and_handle_definition(&id); </ins> visit::walk_path(self, path); }

Discussion:
This may be related to but here is some test code for this specific case: Which prints: Ideally this would not issue a warning.
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. // compile-pass macro_rules! m { () => {{ fn f(_: impl Sized) {} f }} } fn main() { fn f() -> impl Sized {}; m!()(f()); } </ins>

Discussion:
This code triggers this ICE with rustc 1.29.0-beta.2 ( 2018-08-05) but compiles fine with current stable 1.28.0:

Not sure if it's really something that is ever gonna happen in real code, but the following ICE's: <details<summaryBacktrace:</summary</details
Just figured out that declaring the existential type like this: won't panic. I guess because its being copied? But I think that it should not be allowed,
A version without transmutes and , but with pointer casts instead:
Change:
<del> //@ known-bug: #121816 fn f<'a, T>(_: &'static &'a (), x: &'a T) -> &'static T { x } trait W<'a> { fn g<T>(self, x: &'a T) -> &'static T; } impl<'a> W<'a> for &'static () { fn g<T>(self, x: &'a T) -> &'static T { f(&self, x) } } </del>

Discussion:
I'll even accept that this is probably UB if I somehow make it work but crashing on is probably not the way. Replacing some with , or with a second lifetime parameter correctly rejects the code. : <details<summary<strongBacktrace</strong</summary<p</p</details
Regression in nightly-2022-06-08 fetching (via remote github) commits from max(, 2022-06-05) to ending github query because we found starting sha: getcommitsbetween returning commits, len: 7 commit[0] 2022-06-06: Auto merge of - flip1995:clippyup, r=Manishearth commit[1] 2022-06-06: Auto merge of - matthiaskrgr:rollup-ajyvjd3, r=matthiaskrgr commit[2] 2022-06-07: Auto merge of - RalfJung:miri, r=RalfJung commit[3] 2022-06-07: Auto merge of - jackh726:remove-borrowck-mode, r=nikomatsakis commit[4] 2022-06-07: Auto merge of - scottmcm:add-coldcc, r=nagisa,lcnr commit[5] 2022-06-07: Auto merge of - Dylan-DPC:rollup-ya51k1k, r=Dylan-DPC commit[6] 2022-06-07: Auto merge of - Dylan-DPC:rollup-0ae3pwp, r=Dylan-DPC
Likely .
Change:
} fn find_entry(&self, id: HirId) -> Option<Entry<'hir>> { <del> Some(self.get_entry(id)) } fn get_entry(&self, id: HirId) -> Entry<'hir> { </del> if id.local_id == ItemLocalId::from_u32(0) { let owner = self.tcx.hir_owner(id.owner); <del> Entry { parent: owner.parent, node: owner.node } </del> <ins> owner.map(|owner| Entry { parent: owner.parent, node: owner.node }) </ins> } else { let owner = self.tcx.hir_owner_nodes(id.owner); <del> let node = owner.nodes[id.local_id].as_ref().unwrap(); // FIXME(eddyb) use a single generic type insted of having both // `Entry` and `ParentedNode`, which are effectively the same. // Alternatively, rewrite code using `Entry` to use `ParentedNode`. Entry { parent: HirId { owner: id.owner, local_id: node.parent }, node: node.node } </del> <ins> owner.and_then(|owner| { let node = owner.nodes[id.local_id].as_ref(); // FIXME(eddyb) use a single generic type insted of having both // `Entry` and `ParentedNode`, which are effectively the same. // Alternatively, rewrite code using `Entry` to use `ParentedNode`. node.map(|node| Entry { parent: HirId { owner: id.owner, local_id: node.parent }, node: node.node, }) }) </ins> } } <ins> fn get_entry(&self, id: HirId) -> Entry<'hir> { self.find_entry(id).unwrap() } </ins> pub fn item(&self, id: HirId) -> &'hir Item<'hir> { match self.find(id).unwrap() { Node::Item(item) => item,

Discussion:
As of rustc 1.43.0-nightly ( 2020-03-15) the Travis CI builds of are failing due to rustc crashing. The crash happens when building the crate, which is a dependency of one of quiche's subcrates. Unfortunately I wasn't able to reproduce this locally, so I can't try the latest master or try to prepare a minimal reproducer, but I can reproduce this realiably on Travis CI, see e.g. https://travis- https://travis- https://travis- https://travis- Could this have something to do with Travis CI specifically? As per above, I don't have specific code that reproduces this. I can only reproduce when building the crate as part of quiche on Travis CI. : <details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
FTR, the docopt crate was last updated almost a year ago, so this is not due to some new code there
Let's see if we can shrink the input to something suitable for a regression test. ping cleanup Also cc
Hey Cleanup Crew ICE-breakers! This bug has been identified as a good "Cleanup ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
This seems to be an issue with It could be we're calling with something that isn't an HIR owner, in which case it should be changed to return instead of panicking. It's odd that it can't be reproduced though.
I can reproduce it by on
I just realized I wasn't actually using rust nightly when I tried to reproduce locally :man_facepalming: so that explains that...
Minimized:
assign
Change:
use marker::Copy; use mem; <del> /// The representation of a Rust slice </del> <ins> /// The representation of a slice like `&[T]`. /// /// This struct is guaranteed to have the layout of types like `&[T]`, /// `&str`, and `Box<[T]>`, but is not the type of such slices /// (e.g. the fields are not directly accessible on a `&[T]`) nor does /// it control that layout (changing the definition will not change /// the layout of a `&[T]`). It is only designed to be used by unsafe /// code that needs to manipulate the low-level details. /// /// However, it is not recommended to use this type for such code, /// since there are alternatives which may be safer: /// /// - Creating a slice from a data pointer and length can be done with ///   `std::slice::from_raw_parts` or `std::slice::from_raw_parts_mut` ///   instead of `std::mem::transmute`ing a value of type `Slice`. /// - Extracting the data pointer and length from a slice can be ///   performed with the `as_ptr` (or `as_mut_ptr`) and `len` ///   methods. /// /// If one does decide to convert a slice value to a `Slice`, the /// `Repr` trait in this module provides a method for a safe /// conversion from `&[T]` (and `&str`) to a `Slice`, more type-safe /// than a call to `transmute`. /// /// # Examples /// /// ``` /// use std::raw::{self, Repr}; /// /// let slice: &[u16] = &[1, 2, 3, 4]; /// /// let repr: raw::Slice<u16> = slice.repr(); /// println!("data pointer = {:?}, length = {}", repr.data, repr.len); /// ``` </ins> #[repr(C)] pub struct Slice<T> { pub data: *const T,

Discussion:
Here's the definition Implementing is done like so: A safe implementation invokes a transmute between arbitrary types. Perhaps is more appropriately an unsafe trait?
Agreed. Unsafe trait is the way to go.
Change:
@$(call E, making src image) $(Q)rm -Rf tmp/dist/$(SRC_PKG_NAME)-image $(Q)mkdir -p tmp/dist/$(SRC_PKG_NAME)-image/lib/rustlib/src/rust <ins> $(Q)echo "$(CFG_VERSION)" > tmp/dist/$(SRC_PKG_NAME)-image/lib/rustlib/src/rust/version </ins> $(Q)tar  -C $(S)  -f - 

Discussion:
Can we include the output of into the source archives? It can be important for beta and nightly. Ideally the download page should also display them.
This should be a pretty easy bug to tackle for anyone aspiring to do so. Let's just create a file called in our tarballs with basically the output of
This will require editing the makefiles in as well as the rustbuild build system in . The version info is in . I realized that the installers already include this info in a file called 'version', so we can just duplicate that logic. Use the same lower case naming for consistency.
Change:
/// The Resolver. This is the type folding engine that detects /// unresolved types and so forth. <del> crate struct Resolver<'cx, 'tcx> { </del> <ins> struct Resolver<'cx, 'tcx> { </ins> tcx: TyCtxt<'tcx>, infcx: &'cx InferCtxt<'cx, 'tcx>, span: &'cx dyn Locatable,

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. --Removing allows the code to compile successfully. <!-- 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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
cc
I dont have too much context on how type folding works, but my guess is we are calling fold sooner that we should. I have this to the for RFC 2229, I'll bring it up during our sync tomorrow.
We want to use .
assign
Error: Parsing assign command in failed: ...'bot assign' ''... Please let know if you're having trouble with this bot.
claim
Thanks
Change:
Def::SelfTy(..) if path.segments.len() == 1 => { return Generic(keywords::SelfType.name().to_string()); } <ins> Def::TyParam(..) if path.segments.len() == 1 => { return Generic(format!("{:#}", path)); } </ins> Def::SelfTy(..) | Def::TyParam(..) | Def::AssociatedTy(..) => true, _ => false, };

Discussion:
E.g. there's no for or .
cc
What sorts of impls would be expected on this page? Listing impls for every (, , , , ) might be excessive, although of course it's better to err on the side of documenting too much than not enough :-)
It might be, yeah. In principle, there should at least be some kind of page I can put some text on, even if it says "Most of the methods aren't shown on this page because it's too primitive" or something.
At least inherent methods should be listed now.
Triage: no change
Since i just did function pointers (), i'll add this while the details are fresh in mind. What details should go here? ? Using for reborrowing and Deref? Copy/paste details from either edition of the book? Leave it as a skeleton and fill it out later? As for what impls to include, my initial thought was to only include impls where it's a reference to a generic. Otherwise it'll show up on the referent's page, like it is now.
Change:
<del> use crate::spec::{LinkerFlavor, LldFlavor, SplitDebuginfo, TargetOptions}; </del> <ins> use crate::spec::{DebuginfoKind, LinkerFlavor, LldFlavor, SplitDebuginfo, TargetOptions}; </ins> use std::borrow::Cow; pub fn opts() -> TargetOptions {

Discussion:
The UEFI targets (x8664-unknown-uefi, i686-unknown-uefi, and aarch64-unknown-uefi) started failing to compile in the latest nightly when using , failing with "LLVM ERROR: dwo only supported with ELF and Wasm". : : Build: searched nightlies: from nightly-2022-08-25 to nightly-2022-08-27 regressed nightly: nightly-2022-08-27 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x8664-unknown-linux-gnu Reproduce with: </detailsCC since bisect pointed to
Can confirm. Definitely needs to be looked into by the team — can you reproduce this?
I see in that is set in . I think that needs to be in , or maybe directly in ? I tested this out locally by using a custom target JSON that matches except adds , and that seems to fix the bug.
Change:
<ins> #![feature(type_alias_impl_trait)] // check-pass trait Trait {} type TAIT = impl Trait; struct Concrete; impl Trait for Concrete {} fn tait() -> TAIT { Concrete } trait OuterTrait { type Item; } struct Dummy<T> { t: T, } impl<T> OuterTrait for Dummy<T> { type Item = T; } fn tait_and_impl_trait() -> impl OuterTrait<Item = (TAIT, impl Trait)> { Dummy { t: (tait(), Concrete), } } fn tait_and_dyn_trait() -> impl OuterTrait<Item = (TAIT, Box<dyn Trait>)> { let b: Box<dyn Trait> = Box::new(Concrete); Dummy { t: (tait(), b) } } fn main() {} </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. --The condition seems complex, but a practical instance is I tried this code: I expected to see this happen: it compiles Instead, this happened: error: Notes: It compiles in , but failed in works, and works <!-- 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. --: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label F-typealiasimpl_trait
works, and breaks
Caused by Any ideas? cc
also works (a version before which is reverted by
TAIT and RPIT were made to work the same in the revert, thus TAIT was changed from before instead of just reverting to the old behaviour. I will need to look at some typeck logs to see what's goin on here
FYI, it seems that the bug is not related to but to every nested .
I've tested with the following codes: It seems that the result of for is wrong: It seems that wasn't be resolved correctly.
I think fixed this (inadvertently?) in
Just tested it and I can confirm it works now! Thanks! BTW, what about adding this issue as a test cast?
Yes a minimized test PR would be appreciated.
claim
Change:
debug!("trait_fty (pre-subst): %s", ty_to_str(tcx, trait_fty)); ty::subst(tcx, &substs, trait_fty) }; <del> debug!("trait_fty: %s", ty_to_str(tcx, trait_fty)); require_same_types( tcx, None, false, cm.span, impl_fty, trait_fty, || fmt!("method `%s` has an incompatible type", tcx.sess.str_of(trait_m.ident))); </del> <ins> let infcx = infer::new_infer_ctxt(tcx); match infer::mk_subty(infcx, false, cm.span, impl_fty, trait_fty) { result::Ok(()) => {} result::Err(ref terr) => { tcx.sess.span_err( cm.span, fmt!("method `%s` has an incompatible type: %s", tcx.sess.str_of(trait_m.ident), ty::type_err_to_str(tcx, terr))); ty::note_and_explain_type_err(tcx, terr); } } </ins> return; // Replaces bound references to the self region with `with_r`.

Discussion:
Right now, a fn implementing an iface method must match the purity of the iface method exactly. This is too strict. We should allow a pure fn to implement an impure fn, and both pure/impure to implement an unsafe fn. UPDATE: Updated title to reflect the real problem here. There is a FIXME in the code in the relevant area. If one declares a trait like: then in the impl, the method should take one type parameter with an bound. We don't really check this correctly though. As far as I can tell, we just check that has one type parameter with one bound, but not precisely what kind of bound it is.
Similarly, in , we require that the bounds on the method parameters be precisely equivalent, which is stronger than necessary. It is sufficient (I believe) that the bounds on the trait be stronger than the bounds on the implementation.
Is this still an issue? It seems to be fixed now.
Still an issue with respect to type parameter bounds.
I don't believe this is backwards incompatible, renominating.
accepted for feature-complete milestone
The following appears to work, but I assume that this is what was talking about:
triage bump. nothing to add.
Accepted for P-backcompat-lang
Added UPDATE to main bug description above.
I had a look at this issue and tried to create a test case. does test case covers the issue you mentioned? This test case fails because it seems like the parameter types are checked in
what error does it fail with? In the you need to use a different type bound for in order to test this issue. To be more precise, the bounds of the implementation should be implied by the bounds of the trait. For example, this should fail:
thanks for the hint, I guess your updated example should indeed test this issue. I'll start working on a patch.