jiebi/CodeConvo huggingface dataset:
Change:
<ins> // check-pass trait Trait {} impl<T> Trait for T {} trait Noop { type Assoc: ?Sized; } impl<T: ?Sized> Noop for T { type Assoc = T; } struct NoopNewtype<T: ?Sized + Noop>(T::Assoc); fn coerce_newtype<T: Trait>(x: &NoopNewtype<T>) -> &NoopNewtype<dyn Trait + '_> { x } fn main() {} </ins>

Discussion:
Example code I'd expect to work (): (in case the example above seems artificial, the I've reduced this from involves using an associated trait to add around sized types, but not , since wouldn't itself work) <hr/I'd expect to work because should hold, after normalization to (which holds here because ), but nothing performs that normalization before coercion gives up entirely. Unlike (where I've been wary of associated types in the past), there should be no weird interactions here, we should be able to largely treat the as a tuple (and we already ensure the type parameter being changed doesn't show up anywhere else in the , anyway). <hr/The and examples get to normalize before asking the trait system about any or obligations - I wonder if we could just normalize here? But we would have to be careful, because we are in a speculative operation, so we would have to use , like this other piece of coercion logic: cc (author of the crate where this could be useful) <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
FWIW, this can be worked around but they're nightly-only and entirely unnecessary if we fix this issue.
Not sure if I should nominate this for compiler team or lang team, but let's try compiler team first.
This removing nomination. please feel free to keep the discussion going on Zulip or even re-nominating it if you consider a re-discussion important.
I'd like to work on this. I haven't worked on the compiler yet, so not sure I'll be able to fix this in a reasonable time. But since it's labelled it's worth giving a try, right? Any advice is appreciated :) claim
I'm not sure if that E-easy label is really accurate! That said, you could try to drop by in #wg-traits on Zulip at some point during one of my morning office hours times, if that works for you (9am-10 US Eastern Time, every day but Tuesday), and we could talk it over.
is this the same as ?
yes, that's the same thing, unsize coercion doesn't properly consider associated types.

(maybe it's time for me to return to this )
if there's anything we can do to help, feel free to poke us; we want this for uazu/qcell. =^-^=
It's been some time this issue was touched, so let me take a look at it.
Change:
// * If no duplicate checking was requested at all, do //   nothing. <del> let mut is_duplicate = false; </del> <ins> let mut duplicate_type = NoError; </ins> let ns = match duplicate_checking_mode { ForbidDuplicateModules => { <del> is_duplicate = child.get_module_if_available().is_some(); </del> <ins> if (child.get_module_if_available().is_some()) { duplicate_type = ModuleError; } </ins> Some(TypeNS) } ForbidDuplicateTypes => { match child.def_for_namespace(TypeNS) { Some(def_mod(_)) | None => {} <del> Some(_) => is_duplicate = true </del> <ins> Some(_) => duplicate_type = TypeError </ins> } Some(TypeNS) } ForbidDuplicateValues => { <del> is_duplicate = child.defined_in_namespace(ValueNS); </del> <ins> if child.defined_in_namespace(ValueNS) { duplicate_type = ValueError; } </ins> Some(ValueNS) } ForbidDuplicateTypesAndValues => {

Discussion:
Code like Generates the error Which is wrong. is not a type, it's a module.
Change:
name = "miri" version = "0.1.0" dependencies = [ <del> "byteorder", </del> "colored", "compiletest_rs", "env_logger 0.7.1",

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri has failing tests. A follow-up PR to the repository is needed to fix the fallout. cc do you think you would have time to do the follow-up work? If so, that would be great! And nominating for compiler team prioritization.
The bot is wrong; it's not that broke Miri, it's
Change:
} /// Stash a given diagnostic with the given `Span` and `StashKey` as the key for later stealing. <del> /// If the diagnostic with this `(span, key)` already exists, this will result in an ICE. </del> pub fn stash_diagnostic(&self, span: Span, key: StashKey, diag: Diagnostic) { let mut inner = self.inner.borrow_mut(); <del> if let Some(mut old_diag) = inner.stashed_diagnostics.insert((span, key), diag) { // We are removing a previously stashed diagnostic which should not happen. old_diag.level = Bug; old_diag.note(&format!( "{}:{}: already existing stashed diagnostic with (span = {:?}, key = {:?})", file!(), line!(), span, key )); inner.emit_diag_at_span(old_diag, span); panic!(ExplicitBug); } </del> <ins> // FIXME(Centril, #69537): Consider reintroducing panic on overwriting a stashed diagnostic // if/when we have a more robust macro-friendly replacement for `(span, key)` as a key. // See the PR for a discussion. inner.stashed_diagnostics.insert((span, key), diag); </ins> } /// Steal a previously stashed diagnostic with the given `Span` and `StashKey` as the key.

Discussion:
I'm seeing an internal compiler error on the following input (found by ):
I ran : That's a rollup commit. Of the components of the rollup, looks to me to be most likely to be related. (cc
Hmm, bummer. It looks like they are getting the same span and so the stashed error is overwritten. We might need to insert a there to handle the possibility of span reuse from different things.
triage: P-high. Removing nomination. Added regression stable-to-stable tag.
Fixed in
Change:
ty::Adt(def, _) => format!("{} `{}`", def.descr(), tcx.def_path_str(def.did)).into(), ty::Foreign(def_id) => format!("extern type `{}`", tcx.def_path_str(def_id)).into(), ty::Array(t, n) => { <ins> if t.is_simple_ty() { return format!("array `{}`", self).into(); } </ins> let n = tcx.lift(n).unwrap(); <del> match n.try_eval_usize(tcx, ty::ParamEnv::empty()) { _ if t.is_simple_ty() => format!("array `{}`", self).into(), Some(n) => format!("array of {} element{}", n, pluralize!(n)).into(), None => "array".into(), </del> <ins> if let ty::ConstKind::Value(v) = n.val { if let Some(n) = v.try_to_machine_usize(tcx) { return format!("array of {} element{}", n, pluralize!(n)).into(); } </ins> } <ins> "array".into() </ins> } ty::Slice(ty) if ty.is_simple_ty() => format!("slice `{}`", self).into(), ty::Slice(_) => "slice".into(),

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<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
It doesn't fixed in rustc 1.52.0-nightly ( 2021-02-14) link to playground : <details<summary<strongBacktrace</strong</summary<p</p</details
i dont think the fix was merged by then. it works in 1.52.0-nightly 2021-02-16 :)

<!-- 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</detailsI think I'm an ICE magnet; this is my fourth one.
I'd like to note that it only ICEs with the wrong return type. The following does not ICE
Change:
pub const EXCEPTION_MAXIMUM_PARAMETERS: usize = 15; pub const EXCEPTION_STACK_OVERFLOW: DWORD = 0xc00000fd; <ins> pub const ERROR_PATH_NOT_FOUND: libc::c_int = 3; </ins> #[repr(C)] #[cfg(target_arch = "x86")] pub struct WSADATA {

Discussion:
read_dir returns ErrorKind::Other for inexistent file. I tried this code I expected to see . Instead it shows Rust version
Change:
<ins> error: generic `Self` types are currently not permitted in anonymous constants --> $DIR/issue-56445-3.rs:4:15 | LL |     ram: [u8; Self::SIZE], |               ^^^^ error: aborting due to previous error </ins>

Discussion:
Reduced test case () from : Another repro case: Original bug report follows If I run on , I get an ICE: I'm using 2018 edition syntax, so I can only test on beta and nightly. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Commenting out the function in makes the ICE go away. The ICE occurs on a as well as a .
Replacing both instances of Self::FRAGMENTLEN in the function with the literal integer 13 makes the ICE go away.
Still reproduces on 1.35.0 and nightly (). <details<summaryClick for backtrace</summaryBacktrace: </details
triage: P-high, removing nomination, assigning to self for initial investigation.
Note: While I replicate the ICE as described on beta, I see a different ICE on nightly on this branch, namely: For reference (in case it matters e.g. for a hypothetical backport) was injected between +nightly-2019-05-25 and +nightly-2019-05-26. Further bisection thanks to rustup-toolchain-install-master "pinpointed" the change to this rollup PR: Auto merge of - Centril:rollup-wmm7qga, r=Centril I'm pretty sure the change in behavior is due to PR . <details<summaryClick for stack trace</summary</details
Okay here is reduced test case ():
another workaround, by the way, is to move the out of the (and then change the use to say instead of )
And yet another workaround is to say instead of in the return type.
I am taking a break for a few months and I wont be able to look at this; unassigning self.
from duplicate :
Another occurrence in
I've been trying to trace this down, and I think it's due to (or at least it's the same code that needs fixed there, in rustctypeck::collect::genericsof). I believe the UniversalRegionIndices aren't being properly populated for the constant, because in the HIR the constant doesn't have a parent. ConstraintConversion needs the UniversalRegionIndices to convert the ReEarlyBound into a RegionVid, but it's missing due to the previous problem.

Simply replacing with makes the last Memory examples compile, but the original example fails later in freescope. I'm super new to the rust compiler, but hopefully someone else can use this information to fix the problem :) I also believe that the const generics issue is separate, but it's possible that I'm simply trying to solve this in the wrong manner, and a correct solution would also solve the const generics issue.
triage: It would be good to at least figure out a way to give a better error message in these array length cases. (other cases include , ...)
Another case in
Triage: is now fixed in the latest nightly (rustc 1.45.0-nightly ( 2020-05-24)) (fixed by ).
Triage: is now fixed in the latest nightly (I think it's fixed by ). (And I've hidden comment as resolved to make the un-fixed ICEs easier to find.)
Triage: The reduced snippet () and are no longer ICE with the latest nightly:
claim
Change:
}; if let Some(snippet) = converter.to_annotation_snippet() { let dl = DisplayList::from(snippet); <del> let dlf = DisplayListFormatter::new(true); </del> <ins> let dlf = DisplayListFormatter::new(true, self.ui_testing); </ins> // FIXME(#59346): Figure out if we can _always_ print to stderr or not. // `emitter.rs` has the `Destination` enum that lists various possible output // destinations.

Discussion:
Part of To support lines in the first column of UI test output, we have to make use of the flag and update the library. Relevant : The relevant PR in the annotate-snippet library and a new version needs to be released. Once that's done, we have to pass as a second argument to . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
modify labels: A-diagnostics E-help-wanted
claim
Change:
} } } <ins> pub struct DefIdCacheSelector; impl<'tcx, V: 'tcx> CacheSelector<'tcx, V> for DefIdCacheSelector { type Cache = DefIdCache<V> where V: Copy; } pub struct DefIdCache<V> { /// Stores the local DefIds in a dense map. Local queries are much more often dense, so this is /// a win over hashing query keys at marginal memory cost (~5% at most) compared to FxHashMap. /// /// The second element of the tuple is the set of keys actually present in the IndexVec, used /// for faster iteration in `iter()`. // FIXME: This may want to be sharded, like VecCache. However *how* to shard an IndexVec isn't // super clear; VecCache is effectively not sharded today (see FIXME there). For now just omit // that complexity here. local: Lock<(IndexVec<DefIndex, Option<(V, DepNodeIndex)>>, Vec<DefIndex>)>, foreign: DefaultCache<DefId, V>, } impl<V> Default for DefIdCache<V> { fn default() -> Self { DefIdCache { local: Default::default(), foreign: Default::default() } } } impl<V> QueryCache for DefIdCache<V> where V: Copy, { type Key = DefId; type Value = V; #[inline(always)] fn lookup(&self, key: &DefId) -> Option<(V, DepNodeIndex)> { if key.krate == LOCAL_CRATE { let cache = self.local.lock(); cache.0.get(key.index).and_then(|v| *v) } else { self.foreign.lookup(key) } } #[inline] fn complete(&self, key: DefId, value: V, index: DepNodeIndex) { if key.krate == LOCAL_CRATE { let mut cache = self.local.lock(); let (cache, present) = &mut *cache; let slot = cache.ensure_contains_elem(key.index, Default::default); if slot.is_none() { // FIXME: Only store the present set when running in incremental mode. `iter` is not // used outside of saving caches to disk and self-profile. present.push(key.index); } *slot = Some((value, index)); } else { self.foreign.complete(key, value, index) } } fn iter(&self, f: &mut dyn FnMut(&Self::Key, &Self::Value, DepNodeIndex)) { let guard = self.local.lock(); let (cache, present) = &*guard; for &idx in present.iter() { let value = cache[idx].unwrap(); f(&DefId { krate: LOCAL_CRATE, index: idx }, &value.0, value.1); } self.foreign.iter(f); } } </ins>

Discussion:
Per-crate cache maps keyed on may be more efficient and/or allow us to use for queries keyed on instead of . We can use specialization (e.g. for splitting into and ), I think. cc
Sounds like a good idea if the lookup array ends up being densely populated enough. In general, we should provide a way to implement customized in-memory caching for specific queries.
Change:
// // [1]: (www.boost.org/doc/libs/1_55_0/doc/html/atomic/usage_examples.html) // [2]: (https://github.com/rust-lang/rust/pull/41714) <del> atomic::fence(Acquire); </del> <ins> acquire!(self.inner().strong); </ins> unsafe { self.drop_slow();

Discussion:
iff the crate contains two or more unit tests. TODO Sanitizers are not yet in tree. (cf. ) cc
Like with I'd be tempted to say these are false positives, but these stack traces don't look so familiar so I'm not certain of that
This will be a false positive because drop_slow uses a fence, and tsan doesn't work with fences.
So I take it this isn't actually a problem since we're just using a fence and tsan doesn't support that? Should we close?
Can the false-positive be worked-around by manually annotating the happens-before relationship? See
Well, maybe if we could conditionally build without the fence (rework to use a load/store instead) when tsan is enabled then the error wouldn't be seen.
Change:
vertical-align: text-bottom; } <del> .module-item.unstable { </del> <ins> .module-item.unstable, .import-item.unstable { </ins> opacity: 0.65; }

Discussion:
See is unstable, however there is no unstable tag showing that, it would be nice if it would, just so it can be seen at a glance without going to their respective pages. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Note that rustdoc already does something similar for : ! It could use a similar format for re-exports.
Really could just copy the existing tags (see -asm) and put em after the path.
claim
Change:
fn print_associated_type( &mut self, ident: ast::Ident, <ins> generics: &ast::Generics, </ins> bounds: &ast::GenericBounds, ty: Option<&ast::Ty>, ) { self.word_space("type"); self.print_ident(ident); <ins> self.print_generic_params(&generics.params); </ins> self.print_type_bounds(":", bounds); <ins> self.print_where_clause(&generics.where_clause); </ins> if let Some(ty) = ty { self.s.space(); self.word_space("=");

Discussion:
The following code: is pretty printed as This presumably also affects procedural macros.
Are there tests intended for pretty printing? I got the impression that folder only tests specific features and bugs, not the form
Change:
<ins> //@ check-pass // Check that we don't hit a query cycle when: // 1. Computing generics_of, which requires... // 2. Calling resolve_bound_vars, which requires... // 3. Calling associated_items, which requires... // 4. Calling associated_type_for_impl_trait_in_trait, which requires... // 5. Computing generics_of, which cycles. pub trait Foo<'a> { type Assoc; fn demo<T>(other: T) -> impl Foo<'a, Assoc = Self::Assoc> where T: Foo<'a, Assoc = ()>; } fn main() {} </ins>

Discussion:
Minimal example (): outputs In the example, the implementation is irrelevant. The definition itself is the cause for error. Removing either the lifetime or the results in successful compilation as expected. I don't understand why it's causing a cycle error, but intuitively I don't see why it should be. Introducing an trait with a blanket implementation is a possible workaround and what I'll be doing while the issue exists.
Change:
fn foo(_1: Foo) -> usize { debug foo => _1;                     // in scope 0 at $DIR/enum_cast.rs:+0:8: +0:11 let mut _0: usize;                   // return place in scope 0 at $DIR/enum_cast.rs:+0:21: +0:26 <del> let mut _2: isize;                   // in scope 0 at $DIR/enum_cast.rs:+1:5: +1:8 </del> <ins> let _2: Foo;                         // in scope 0 at $DIR/enum_cast.rs:+1:5: +1:8 let mut _3: isize;                   // in scope 0 at $DIR/enum_cast.rs:+1:5: +1:8 </ins> bb0: { <del> _2 = discriminant(_1);           // scope 0 at $DIR/enum_cast.rs:+1:5: +1:17 _0 = move _2 as usize (IntToInt); // scope 0 at $DIR/enum_cast.rs:+1:5: +1:17 </del> <ins> StorageLive(_2);                 // scope 0 at $DIR/enum_cast.rs:+1:5: +1:8 _2 = move _1;                    // scope 0 at $DIR/enum_cast.rs:+1:5: +1:8 _3 = discriminant(_2);           // scope 0 at $DIR/enum_cast.rs:+1:5: +1:17 _0 = move _3 as usize (IntToInt); // scope 0 at $DIR/enum_cast.rs:+1:5: +1:17 StorageDead(_2);                 // scope 0 at $DIR/enum_cast.rs:+1:16: +1:17 </ins> return;                          // scope 0 at $DIR/enum_cast.rs:+2:2: +2:2 } }

Discussion:
noticed this 1.63→1.64 change in I tried this code: I expected to see this happen: because is non-, an error about moving out from behind a reference, like happened in 1.63 , this happened: it compiles fine in 1.64 in nightly is probably cased by Change enum-int casts to not go through MIR casts which is mentioned in It's unclear to me whether this is intentional under the banner of " behaviour", since there's no trait involved.
Prioritized as P-critical in meeting just now. This needs to be fixed by 1.65 at a minimum.
labels +T-compiler This needs work from T-compiler! :)
labels -I-lang-nominated Meeting consensus is that the current behavior is wrong and needs to be fixed.
Change:
#[stable(feature = "rust1", since = "1.0.0")] unsafe impl Send for Once {} <ins> #[stable(feature = "sync_once_unwind_safe", since = "1.59.0")] impl UnwindSafe for Once {} #[stable(feature = "sync_once_unwind_safe", since = "1.59.0")] impl RefUnwindSafe for Once {} </ins> /// State yielded to [`Once::call_once_force()`]’s closure parameter. The state /// can be used to query the poison status of the [`Once`]. #[stable(feature = "once_poison", since = "1.51.0")]

Discussion:
Currently, the following program because isn't . Is this the desired behavior, or should we consider making it or ? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It also won't compile because ?
Ah, right you are. :
does not require anymore (tested with rustc 1.55.0). The original issue is still valid. Since poisons itself on panic, it should be considered unwind safe.
We discussed this very briefly in the libs api meeting. It seems fine to add this impl.
claim Going to take a stab at this one.
Change:
<del> error[E0267]: `break` inside of a closure </del> <ins> error[E0267]: `break` inside of an async block </ins> --> $DIR/async-block-control-flow-static-semantics.rs:35:9 | LL |         break 0u8; <del> |         ^^^^^^^^^ cannot break inside of a closure </del> <ins> |         ^^^^^^^^^ cannot break inside of an async block </ins> <del> error[E0267]: `break` inside of a closure --> $DIR/async-block-control-flow-static-semantics.rs:43:13 </del> <ins> error[E0267]: `break` inside of an async block --> $DIR/async-block-control-flow-static-semantics.rs:42:13 </ins> | LL |             break 0u8; <del> |             ^^^^^^^^^ cannot break inside of a closure </del> <ins> |             ^^^^^^^^^ cannot break inside of an async block </ins> error[E0308]: mismatched types --> $DIR/async-block-control-flow-static-semantics.rs:15:43

Discussion:
With: you get: Note how it references "a closure" which seems confusing for a user who doesn't presume the implementation. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
I'm assuming its ok to leave this as the same error code of E0267 - in essence it's the same error, just more specific text.
Yeah I think it's fine.