jiebi/CodeConvo huggingface dataset:
Change:
out: Vec<traits::PredicateObligation<'tcx>>, } <ins> /// Controls whether we "elaborate" supertraits and so forth on the WF /// predicates. This is a kind of hack to address #43784. The /// underlying problem in that issue was a trait structure like: /// /// ``` /// trait Foo: Copy { } /// trait Bar: Foo { } /// impl<T: Bar> Foo for T { } /// impl<T> Bar for T { } /// ``` /// /// Here, in the `Foo` impl, we will check that `T: Copy` holds -- but /// we decide that this is true because `T: Bar` is in the /// where-clauses (and we can elaborate that to include `T: /// Copy`). This wouldn't be a problem, except that when we check the /// `Bar` impl, we decide that `T: Foo` must hold because of the `Foo` /// impl. And so nowhere did we check that `T: Copy` holds! /// /// To resolve this, we elaborate the WF requirements that must be /// proven when checking impls. This means that (e.g.) the `impl Bar /// for T` will be forced to prove not only that `T: Foo` but also `T: /// Copy` (which it won't be able to do, because there is no `Copy` /// impl for `T`). #[derive(Debug, PartialEq, Eq, Copy, Clone)] enum Elaborate { All, None, } </ins> impl<'a, 'gcx, 'tcx> WfPredicates<'a, 'gcx, 'tcx> { fn cause(&mut self, code: traits::ObligationCauseCode<'tcx>) -> traits::ObligationCause<'tcx> { traits::ObligationCause::new(self.span, self.body_id, code)

Discussion:
First reported in cc - let's discuss this when you are back from vacation (unless can come up with a solution?)
Associated types variant, which bypasses some fixes based only on supertraits:
Chalk's strategy will solve this, but I guess that shouldn't be extremely difficult to fix even with the current strategy. The first impl is valid: since indeed implies that . The second however, is not: the impl declaration should be able to prove that holds (ok because of the first impl), but also that is well-formed, i.e. that holds. Same thing in the second example, this impl declaration: should prove that (ok) and that is well-formed, i.e. . The latter is not being proved currently.
triage: P-high -- has pending fix
Change:
let is_input = i < ii.len(); if is_arg && is_input && matches!(mat[i][i], Compatibility::Compatible) { // This is a satisfied input, so move along <ins> next_unmatched_idx += 1; </ins> continue; }

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: the compiler giving an error and showing a hint that order of the argument are not correct. Instead, this happened: it stucks, waits forever. It happens on both stable and nightly. Might be related to this:
Yeah, this is probably a dupe of that other one. cc
Yes, it's another bug in the same function, but the root cause is different. I will working on the same PR for this issue.
Change:
<ins> //@ compile-flags: -Cdebuginfo=2 --crate-type=lib //@ build-pass #![feature(adt_const_params)] const N_ISLANDS: usize = 4; pub type Matrix = [[usize; N_ISLANDS]; N_ISLANDS]; const EMPTY_MATRIX: Matrix = [[0; N_ISLANDS]; N_ISLANDS]; const fn to_matrix() -> Matrix { EMPTY_MATRIX } const BRIDGE_MATRIX: [[usize; N_ISLANDS]; N_ISLANDS] = to_matrix(); pub struct Walk<const CURRENT: usize, const REMAINING: Matrix> { _p: (), } impl Walk<0, BRIDGE_MATRIX> { pub const fn new() -> Self { Self { _p: () } } } </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. --: rustc -Cdebuginfo=2 --crate-type lib <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I guess this is now reachable without debug assertions cc
not entirely sure why that assertion fails but: good?
Change:
assert_eq!(data, data2); } <ins> #[test] fn test_cow_from() { let borrowed = "borrowed"; let owned = String::from("owned"); match (Cow::from(owned.clone()), Cow::from(borrowed)) { (Cow::Owned(o), Cow::Borrowed(b)) => assert!(o == owned && b == borrowed), _ => panic!("invalid `Cow::from`"), } } </ins> mod pattern { use std::str::pattern::Pattern; use std::str::pattern::{Searcher, ReverseSearcher};

Discussion:
Both Vec<Tand &[T] are missing From impls for Cow, unlike String/&str and PathBuf/&Path. Coherence is not (afaict) an issue, since the impl would be in the same crate as Cow. Is there some reason these don't exist (do they cause coherence issues in downstream crates or something)?
Whoa, I have no idea why these aren't implemented... Should be good to go ahead and add them! Want to send a PR?
Change:
<ins> // edition:2018 #![deny(unreachable_code)] async fn foo() { return; bar().await; //~^ ERROR unreachable statement } async fn bar() { } fn main() { } </ins>

Discussion:
I tried this code: I expected to see this happen: no build warn Instead, this happened: :
We . The likely cause is that parts of the await desugaring are being linted against. We can likely check the span to see if the code that is being linted against is part of the desugaring, but we do want to be careful to ensure that still gets a lint warning.
Marking as deferred as this doesn't seem like a problem that needs to block stabilization.
cc who has done some work on the inhabited logic stuff.
I'm now getting this warning even for functions that loop but eventually return. It worked fine with nightly-2019-08-21, but the latest nightly (2019-09-17) is broken. For example, this code generates a warning: with the warning repeated twice:
Can confirm. I believe this regressed somewhere after nightly 09-09-2019.
I think I have this in my code here: Can somebody confirm this? If not I'll file another bug report.
yeah that's the same, the function can "never" return from the unconditional loop.
Change:
<ins> #![feature(existential_type)] trait UnwrapItemsExt { type Iter; fn unwrap_items(self) -> Self::Iter; } impl<I, T, E> UnwrapItemsExt for I where I: Iterator<Item = Result<T, E>>, E: std::fmt::Debug, { existential type Iter: Iterator<Item = T>; //~^ ERROR: could not find defining uses fn unwrap_items(self) -> Self::Iter { //~^ ERROR: type parameter `T` is part of concrete type //~| ERROR: type parameter `E` is part of concrete type self.map(|x| x.unwrap()) } } fn main() {} </ins>

Discussion:
probably related to
cc might not be impl-trait-in-let-binding related after all
Ah, good to know. Are you going to tackle this? I'm not sure if the RFC for should support this syntax (I suspect not), but it would be nice (for the sake of my upcoming PR) to support within impls at an HIR level, at least.
Existential types for associated types in trait impls are already supported and suggested to exist by the RFC. The issue here is probably that I never considered generics in that light. Or am I misunderstanding what you mean by "this syntax"?
Ah, I was probably thinking of the case of inherent impls... glad these are supported.
The ICE doesn't appear on the latest nightly via the above link.
Good spot. Not sure what PR fixed this, but I suspect it can be closed now...
Before closing this, we can add the tests for this.
It depends if there is already an equivalent (minimal) example. If there is, no need... if not, then yes (and let's minimise this one).
It's sorta harder to minimize something that no longer ICEs... I think it would be sufficient to simply add a test with the above snippet for now and close the issue after.
Fair point. I mean, we could use an old nightly, but that's a pain.
Change:
Some(self.cap) } <del> /// Disconnects the channel and wakes up all blocked senders and receivers. </del> <ins> /// Disconnects senders and wakes up all blocked receivers. </ins> /// /// Returns `true` if this call disconnected the channel. <del> pub(crate) fn disconnect(&self) -> bool { </del> <ins> pub(crate) fn disconnect_senders(&self) -> bool { </ins> let tail = self.tail.fetch_or(self.mark_bit, Ordering::SeqCst); if tail & self.mark_bit == 0 { <del> self.senders.disconnect(); </del> self.receivers.disconnect(); true } else {

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --I tried this code: I expected to see this happen: I expected to see the struct in the Sender buffer get dropped after the Receiver is dropped during the unwind of the panicking thread. Instead, this happened: The data in the Sender buffer is not dropped until the whole process ends. <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.47 --It most recently worked on: 1.66.1 <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --</p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-{channel} -regression-untriaged --
bisection seems to point to cc searched nightlies: from nightly-2022-11-01 to nightly-2023-02-01 regressed nightly: nightly-2022-11-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.5</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with:
In crossbeam, the unbounded channel does this (), but the bounded channel does not. There is no particular intent, it just hasn't been implemented. cc
Change:
} #[test] <del> fn test_unsafe_mutex_arc_nested() { unsafe { // Tests nested mutexes and access // to underlaying data. let arc = ~MutexArc::new(1); let arc2 = ~MutexArc::new(*arc); task::spawn(proc() { (*arc2).unsafe_access(|mutex| { (*mutex).access(|one| { assert!(*one == 1); }) </del> <ins> fn test_mutex_arc_nested() { // Tests nested mutexes and access // to underlaying data. let arc = ~MutexArc::new(1); let arc2 = ~MutexArc::new(*arc); task::spawn(proc() { (*arc2).access(|mutex| { (*mutex).access(|one| { assert!(*one == 1); </ins> }) <del> }); } </del> <ins> }) }); </ins> } #[test]

Discussion:
contains two sets of methods to access the Arc's wrapped object. and are tagged unsafe as "it is possible to construct a circular reference among multiple Arcs by mutating the underlying data. This creates potential for deadlock, but worse, this will guarantee a memory leak of all involved Arcs." There are also and methods defined when the inner type is freezable as that guarantees the type can't contain a . However, it's still trivially easy to deadlock using the safe methods: It seems that the consensus in was that possibility of deadlock is inherently unsafe, so should and be removed? cc
Perhaps access should fail when it is called by the same task twice? It would be nice if people didn't have to use unsafe blocks just to get normal stuff done.
Nested locks in the same task aren't the only way you can run into deadlock:
I am aware of that, but it seems to me this particular error would be easy and cheap to catch, so if we aren't doing that yet, we probably should. Personally I don't think the possibility of a deadlock should require an unsafe block.
Consensus in the past has been that deadlock is not unsafe (). You can deadlock with pipes too, with just two lines of code. The non- accessors for are unsafe for a totally different reason, which is documented in . Regarding "cheap and easy to catch" - I don't believe we should try to fail in the single-task deadlock case unless we can reliably fail in all deadlock cases (which is not out of the question but requires scheduler support, see ). A user who is used to seeing a failure message from their previous attempts which had deadlocked would be all the more confused when they find their cross-task deadlocking code does not fail.
Is the possibility of memory leakage really considered unsafe? doesn't seem to share that assumption, but I may be missing something there.
Neither or provides a way to leak memory via the safe constructors.
We currently don't officially consider leaks to be , but I think leaking past the lifetime of tasks with references is a very questionable thing to allow.
The box annihilator is not a good solution to rc reference cycles, but it is at least a solution. Cycles of MutexArcs will produce valgrind errors.
now provides a way to leak with the safe constructors.
Change:
Nomicon, "src/doc/nomicon", "nomicon"; Reference, "src/doc/reference", "reference"; Rustdoc, "src/doc/rustdoc", "rustdoc"; <ins> RustByExample, "src/doc/rust-by-example", "rust-by-example"; </ins> ); #[derive(Debug, Copy, Clone, Hash, PartialEq, Eq)]

Discussion:
This is an issue for moving Rust By Example, which is currently at , to . I will be working on the first step shortly. [x] Convert RBE to a submodule under [x] Add RBE to the bookshelf (thanks [x] Update book release process on forge After it is converted and RBE reaches stable: [ ] Update the main English website link a 301
Step one done! Now waiting for this to reach stable.
The forge documentation can be updated now.
This has all been done!
Change:
<del> error[E0275]: overflow evaluating the requirement `RootDatabase: RefUnwindSafe` </del> <ins> error[E0275]: overflow evaluating the requirement `SalsaStorage: RefUnwindSafe` </ins> --> $DIR/cycle-cache-err-60010.rs:27:13 | LL |     _parse: <ParseQuery as Query<RootDatabase>>::Data, |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | <ins> note: required because it appears within the type `PhantomData<SalsaStorage>` --> $SRC_DIR/core/src/marker.rs:LL:COL note: required because it appears within the type `Unique<SalsaStorage>` --> $SRC_DIR/core/src/ptr/unique.rs:LL:COL note: required because it appears within the type `Box<SalsaStorage>` --> $SRC_DIR/alloc/src/boxed.rs:LL:COL note: required because it appears within the type `Runtime<RootDatabase>` --> $DIR/cycle-cache-err-60010.rs:23:8 | LL | struct Runtime<DB: Database> { |        ^^^^^^^ note: required because it appears within the type `RootDatabase` --> $DIR/cycle-cache-err-60010.rs:20:8 | LL | struct RootDatabase { |        ^^^^^^^^^^^^ </ins> note: required for `RootDatabase` to implement `SourceDatabase` --> $DIR/cycle-cache-err-60010.rs:44:9 |

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: This is modification of with the difference being ` Rust OOM'd here after eating at least 20 gb of memory :sweat_smile: I expected to see this happen: explanation NO OOM, maybe an error Instead, this happened: explanation OOM <!-- 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. --:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Change:
} } } else { <del> // Cross-crate closure types should only be // visible in codegen bug reports, I imagine. p!(write("@{:?}", did)); </del> <ins> p!(write("@{}", self.tcx().def_path_str(did))); </ins> if substs.as_closure().is_valid() { let upvar_tys = substs.as_closure().upvar_tys();

Discussion:
Follow-up of Consider this example: It emits the stderr on my local (x86_64-unknown-linux-gnu): But on some other environment on CI, e.g. or , it emits it with a tiny difference: It's ideal to have the same diagnostics on all the environment. See also:
s shouldn't be leaked in user output.
Yeah, other places look like: Perhaps we emit accidentally in somewhere.
that makes me think that we probably have some instead of somewhere.
The relevant code is: I don't find any difference between here and similar places yet. thoughts?
the place to look at is: CC The same applies to closures, but we are likely not displaying them this way anywhere (or we've just gotten lucky).
Change:
any(target_arch = "aarch64", target_arch = "riscv64") ), all(target_os = "nto", target_arch = "aarch64"), <del> target_os = "horizon" </del> <ins> target_os = "horizon", target_os = "aix", </ins> ))] { pub type c_char = u8; } else {

Discussion:
Currently, core::ffi::c_char on AIX is i8, but AFAIK, the default of this platform is unsigned (u8). : Clang: Rust: cc () <!-- 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. --:
I opened and as drafts to fix this, but I want feedback from the target maintainers before undrafting/merging them.
Ideally, we could detect such a problem in CI by . However, AFAIK, most tier3 targets are not checked at all in CI at this time (), so that would need to be fixed first.
Yes, we should follow clang on AIX's behavior.
Change:
// interned this?  I thought that is the entire point of that `FinishStatic` stuff? let alloc = ecx.tcx.intern_const_alloc(alloc); let val = ConstValue::ByRef(ptr, alloc); <del> Ok(ty::Const { val, ty: mplace.layout.ty }) </del> <ins> ty::Const { val, ty: mplace.layout.ty } </ins> } fn op_to_const<'tcx>( ecx: &CompileTimeEvalContext<'_, '_, 'tcx>, op: OpTy<'tcx>, <del> ) -> EvalResult<'tcx, ty::Const<'tcx>> { // We do not normalize just any data.  Only scalar layout and slices. </del> <ins> ) -> ty::Const<'tcx> { // We do not normalize just any data.  Only non-union scalars and slices. </ins> let normalize = match op.layout.abi { <del> layout::Abi::Scalar(..) => true, </del> <ins> layout::Abi::Scalar(..) => op.layout.ty.ty_adt_def().map_or(true, |adt| !adt.is_union()), </ins> layout::Abi::ScalarPair(..) => op.layout.ty.is_slice(), _ => false, };

Discussion:
It looks like this was broken in the release of 1.32.0 (and is still broken, even on nightly) (checked on ). The following example program: Fails to compile: Interestingly, making the fixes it. My Rust version: I know , but I don't think this qualifies as a field access. And yes, I'm aware of . cc
Interesting. Looks like a validation issue? Cc
Change:
<ins> // check-pass #![feature(dyn_star)] #![allow(incomplete_features)] trait AddOne { fn add1(&mut self) -> usize; } impl AddOne for usize { fn add1(&mut self) -> usize { *self += 1; *self } } impl AddOne for &mut usize { fn add1(&mut self) -> usize { (*self).add1() } } fn add_one(mut i: dyn* AddOne + '_) -> usize { i.add1() } fn main() { let mut x = 42usize; let y = &mut x as (dyn* AddOne + '_); println!("{}", add_one(y)); } </ins>

Discussion:
Test case (: This gives the following error message:
label +C-bug +T-compiler +I-ICE +F-dyn_star +requires-nightly
A smaller sample that ICE's with the same message:
The sample provided by DutchGhost compiles now, and the one that provided compiles with some slight modification (adding some lifetimes so borrowck is happy):
Change:
RedundantImport(Vec<(Span, bool)>, Ident), DeprecatedMacro(Option<Symbol>, Span), UnusedDocComment(Span), <ins> PatternsInFnsWithoutBody(Span, Ident), </ins> } /// Lints that are buffered up early on in the `Session` before the

Discussion:
Taken from We should suggest to use an identifier. When possible take that identifier from the pattern, otherwise should work just as well. CC
I'll try it!
Change:
let mut cmd = Command::new(cargo_clippy); cmd.env(helpers::dylib_path_var(), env::join_paths(&dylib_path).unwrap()); <del> cmd.env("PATH", path); </del> <ins> cmd.env("CARGO", &self.initial_cargo); </ins> cmd }

Discussion:
Previously, clippy was using from , but since , it now prioritizes checking first. We can now set path into and avoid appending it to the chain. In the bootstrap, we have this piece of code which adds into . As indicated by the FIXME note, wasn't merged at the time. Now that we can do so, set instead of and remove the FIXME note. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
There's more weird stuff going on here... On Windows, is PATH, so this sets the PATH and then immediately overwrites it again with a different value...?!? This almost looks like it may want to call or . It's not quite equivalent though. Unfortunately there are no comments explaining why it does what it does... Cc who wrote that code, but it's been two years so not sure if they remember.^^
Yep, sorry, absolutely no clue what that code is meant to do. It's very likely that I copied that from somewhere else during the initial stages of "try everything and see if any of it works", or copied some part of that, and eventually modified to set . I have also unfortunately forgotten all of the context of the bootstrap code here, how it's meant to flow, and what it's meant to set for other programs, so I will not be of any help here :c I will try to check my messages with jyn, who i was talking to a lot about this at the time, and trying many things at their suggestion, to see if I can find any useful history.
Change:
<ins> error[E0277]: `!` is not an iterator --> $DIR/issue-51506.rs:13:5 | LL |     type Out: Iterator<Item = u32>; |     ------------------------------- required by `Trait::Out` ... LL |     default type Out = !; |     ^^^^^^^^^^^^^^^^^^^^^ `!` is not an iterator | = help: the trait `std::iter::Iterator` is not implemented for `!` error: aborting due to previous error For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
This snippet is found in . Reduced: :
Nitpick: There's no need to put the two into different functions, you can put them both in .
Like , when using an anonymous binding (), the above code :
No longer ICEs since

With specialization, it is possible to define a default associated type that does not fulfill its trait bounds. Here is a minimal example, that surely should not compile, but does with rustc 1.35.0-nightly: Unsurprisingly, adding the main function causes an ICE. Error message and backtrace (compiled at the playground):
Triage: the latest nightly rejects the code, marking as E-needs-test.

This code generates an ICE with this message. Replacing by makes the code to compile and run fine, which is strange because ! does not implements . By removing the specialization the compiler refuses to compile the code with the error:
The ICE has been fixed in the latest nightly, marked as E-needstest
Thanks Indeed, the example compiles fine in nightly ( 2019-11-12), however, replacing the main function by these two generates the same ICE.
ah, thanks for the update! I confirmed it ()
Triage: the ICE doesn't occur anymore with the latest nightly, marking as E-needs-test.

I was attempting to figure out the feature landscape for , and I found this ICE when playing with it and specialization:
The given code builds fine on current nightly.
This is still an ICE on current nightly when not .
This code compiles without a problem whether I do or using current nightly: . Tested on Windows 10 x64 and Ubuntu x64.
Really? But on the playground, the ICE still appears. Can you check the above link?
Yes, I get an ICE in the playground when I just build.
It does ICE when using instead of .
You need or , not . It seems like a still ICE to me.
Triage: the latest nightly rejects the code without an ICE. Marking as E-needs-test.