jiebi/CodeConvo huggingface dataset:
Change:
<ins> // #66353: ICE when trying to recover from incorrect associated type trait _Func<T> { fn func(_: Self); } trait _A { type AssocT; } fn main() { _Func::< <() as _A>::AssocT >::func(()); //~^ ERROR the trait bound `(): _A` is not satisfied //~| ERROR the trait bound `(): _Func<_>` is not satisfied } </ins>

Discussion:
When using zipped iterators in a certain section of code, I hit an ICE. I've attached the project source -- sorry I could not produce a minimum example though I tried. Also, it's closed source, though I own it so can choose to provide the snapshot. Symptoms: Normally using zipped iterators doesn't cause an ICE, but in this case it is consistent (clean build, using , and ). Not zipping the iterators, and using prevents the ICE from occurring. This code fails to compile: This code compiles: Compilation error message: : 1.39 (stable): 1.40 (nightly): Backtrace: <details<summary1.39 stable</summary</details<details<summary1.40 nightly</summary</detailsInvestigation: Steps to reproduce: and run Relevant source file: Interestingly, using on the iterator on the ICE-ing code allows it to compile: Also interestingly, using the version within without also causes the ICE, so it's not the zipping that's causing it, but rather something to do with the being a reference rather than an owned value.
Seems to be an issue with Crash on stable, beta, nightly
regression from stable-to-stable 38.0 "worked"
A reduction would be good :)
I'm on it.
You want a MCVE? I give you a MCVE! modify labels: -E-needs-mcve +E-needs-bisection
Reduced:
regression between ...
cc
is the one to blame .
triage: P-high. Removing nomination label.
Change:
//! propagating default levels lexically from parent to children ast nodes. use rustc_attr::{ <del> self as attr, ConstStability, Stability, StabilityLevel, Unstable, UnstableReason, </del> <ins> self as attr, rust_version_symbol, ConstStability, Stability, StabilityLevel, Unstable, UnstableReason, VERSION_", </ins> }; use rustc_data_structures::fx::{FxHashMap, FxHashSet, FxIndexMap}; use rustc_errors::{struct_span_err, Applicability};

Discussion:
with rustc master looks like the stabilisation version is borked? :sweat_smile: cc
Hm, it actually says it like this in the code :D
This is correct, but not ideal: https://rustc-dev- cc maybe we want to special case this in the diagnostics
Yeah seems I've missed correcting that lint. For GATs, the stabilization version will be adjusted very soon, in the coming days, as we are close to the release cycle. But this needs to be fixed for future stabilizations as well. Working on a PR. label bug
Error: Label bug can only be set by Rust team members Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
Yeah it warns correctly for lib features so only lang features are affected:
PR filed:
Change:
use rustc_middle::ty::{self, ConstKind, Instance, InstanceDef, ParamEnv, Ty, TyCtxt}; use rustc_session::config::OptLevel; use rustc_span::{hygiene::ExpnKind, ExpnData, LocalExpnId, Span}; <ins> use rustc_target::abi::VariantIdx; </ins> use rustc_target::spec::abi::Abi; use super::simplify::{remove_dead_blocks, CfgSimplifier};

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. --ICE is triggered when building in file in release mode. I'm not able to reproduce when building in debug mode. In my situation, the crate is built as part of the dependency tree for a binary crate. <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
cc this seems like those mir-inliner bugs :thinking:
Bisected to which is likely (similar as issues and ).
Saw a couple of these in Crater, though typically with some other ICEs too (which is why I didn't file bugs). But tagging as 1.64 and beta regression.
For the record, that PR probably revealed this bug but is likely not the cause of it.
Indeed, that's the "usual" normalization failure ICE we have with the MIR inliner. When enabling the MIR inliner, I only a check that we don't have such type mismatch at the signature, but I did not attempt to check all types that appear in the MIR for such mismatch. If we want to fully avoid this ICE, we'd need to fully visit the callee body to check for those type mismatches. do you know if progress has been made on the normalization front?
Hmm, maybe this is fixed by , but I don't have time to investigate this right now. Edit: It's not fixed.
Do you think it may make sense to disable the MIR inliner on beta to give it some more time to bake? I think it was switched on mid-cycle in 1.64, right?
I qualify this as a bug in type normalization that MIR validation exposes. It's not a bug in the MIR inliner.

There are 3 ways to address this: more exceptions to the MIR inliner to avoid those bugs (easy but cumbersome, ); type normalization (very hard); MIR validation (tentative in ); validating MIR in released compilers but keep doing it on tests (very easy). However, I don't think that disabling the MIR inliner will help.
Stopping to validate MIR sounds like a really bad idea to me. MIR validation (in released compilers) has caught many critical issues already like (I found it while investigating a MIR validation failure that someone found in the wild because the mir typeck found something typeck let through) and the most recent let_chains problem which was also found because of a MIR validation ICE.
WG-prioritization assigning priority (). label -I-prioritize +P-critical
Reduced example: label S-bug-has-mcve
Weird, this one crashes with but I couldn't get this to trigger with just mir-opt-levels :thinking:
Change:
// Some subcommands get extra options match subcommand.as_str() { <del> "test" => { </del> <ins> "test" | "t" => { </ins> opts.optflag("", "no-fail-fast", "Run all tests regardless of failure"); opts.optmulti("", "test-args", "extra arguments", "ARGS"); opts.optmulti(

Discussion:
currently supports , and a few others even though not so discoverable (). It would be good to let supports the aliases supported by , such as , and such. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
end: RangeEnd, }, <del> /// matches against a slice, checking the length and extracting elements </del> <ins> /// matches against a slice, checking the length and extracting elements. /// irrefutable when there is a slice pattern and both `prefix` and `suffix` are empty. /// e.g. `&[ref xs..]`. </ins> Slice { prefix: Vec<Pattern<'tcx>>, slice: Option<Pattern<'tcx>>,

Discussion:
Irrefutable slice patterns with a may cause the compiler to ICE. I expected to see this happen: the code compiled (however silly this example is) Instead, this happened: : rustc 1.24.0-nightly ( 2017-12-30) binary: rustc commit-hash: commit-date: 2017-12-30 host: x86_64-unknown-linux-gnu release: 1.24.0-nightly LLVM version: 4.0 Backtrace:
It also occurs with:
Change:
/// Checks whether the regions of memory starting at `src` and `dst` of size /// `count * size_of::<T>()` overlap. <del> #[cfg(not(miri))] // Cannot compare with `>` across allocations in Miri </del> fn overlaps<T>(src: *const T, dst: *const T, count: usize) -> bool { let src_usize = src as usize; let dst_usize = dst as usize;

Discussion:
Hello, this is your friendly neighborhood mergebot. After merging PR rust-lang/rust, I observed that the tool miri no longer builds. 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! cc the PR reviewer, and -- nominating for prioritization.
Change:
<del> -include ../tools.mk # Make sure we don't ICE if the linker prints a non-UTF-8 error message. # ignore-windows # # This does not work in its current form on windows, possibly due to # gcc bugs or something about valid Windows paths.  See issue #29151 # for more information. # ignore-macos # # This also does not work on Apple APFS due to the filesystem requiring # valid UTF-8 paths. # The zzz it to allow humans to tab complete or glob this thing. bad_dir := $(TMPDIR)/zzz$$'xff' all: $(RUSTC) library.rs mkdir $(bad_dir) mv $(TMPDIR)/liblibrary.a $(bad_dir) $(RUSTC) -L $(bad_dir) exec.rs 2>&1 | $(CGREP) this_symbol_not_defined </del>

Discussion:
when running locally I get errors in the test : The most notable part being this: perhaps related to the linker on my system?
Compiler team pre-triage: marking as P-medium, this is probably something wacky in my local setup. We'll see if others complain about it.
I have also seen this in Fedora and RHEL builds, but I didn't worry enough to chase it down yet. This error is actually from itself: Arguments 5 and 6 from the command in your report are: -L /home/nmatsakis/versioned/rust-6/build/x8664-unknown-linux-gnu/test/run-make-fulldeps/linker-output-non-utf8/linker-output-non-utf8/zzz$'xff' That line is deliberately in the test: I have no idea why this isn't an issue in CI though...
Oh, I think I do know why. That in the Makefile is assuming shell expansion of that (with doubled to escape from itself). Fedora and RHEL use -which does expand it, but Debian and Ubuntu (used in CI) have -, which is a more limited shell. bash: dash: So I think this test hasn't really been working as desired on -using platforms at all, since the isn't really "bad" when not escaped. And it can't work even then because won't accept non-utf8 arguments in the first place, never mind reaching the linker.
Note, the and builders do use CentOS 5 as the base image, which would have this issue too, but we don't actually run tests there. It would be nice to add some diversity to the testing images, either with Fedora or perhaps the redistributable .
Any idea what to do with this test? Having to use for over two weeks isn't very practical.
We can probably just remove that test, it doesn't seem worth the pain of having it if it's causing people problems. It sounds like we don't have a test case that would work universally even on *nix platforms, right? Or that's my interpretation of at least. It's also pretty unclear to me that ICE-ing on non-utf8 output from linkers is something we need to test for. That sounds both incredibly uncommon, and also pretty easily fixable if we need to.

One thought for testing this is to override the linker rustc uses with a shell script or even a rust program that runs the linker internally but just does something like or with some non-utf8 output.
This test continues to be super annoying. I'm happy to just remove it, per suggestion.
Okay I've filed to remove the test -- seems like everyone is in agreement it does not pull its weight.
Change:
<ins> // Regression test for issue #57642 // Tests that we reject a bad higher-ranked subtype // with `#![feature(nll)]` #![feature(nll)] trait X { type G; fn make_g() -> Self::G; } impl<'a> X for fn(&'a ()) { type G = &'a (); fn make_g() -> Self::G { &() } } trait Y { type F; fn make_f() -> Self::F; } impl<T> Y for fn(T) { type F = fn(T); fn make_f() -> Self::F { |_| {} } } fn higher_ranked_region_has_lost_its_binder() { let x = <fn (&())>::make_g(); //~ ERROR no function } fn magical() { let x = <fn (&())>::make_f(); //~ ERROR no function } fn main() {} </ins>

Discussion:
The following code example () produces the output <details</detailsThe second example also unexpectedly compiles in full NLL mode.
I renamed the title to focus on the part I would most like to investigate, which is why this function works but only with feature-nll: That seems like a blocker to disabling migration mode.
cc
marking P-medium to reflect that this is solely about , not migration mode (). When the latter becomes higher priority, this will likewise be raised up.
Update: this is only an issue now with
blocks
Diagnostics triage: this is not a diagnostics issue
This is now a compiler error with :
Yes, but it should be two compiler errors, one in makef and one on makeg.
Looking at this further - why don't we want to compile? It looks perfectly correct to me.
Running this example with my branch from yields, among some other errors: This error seems correct. If I had to guess the problem with NLL, though, I would guess that this is working because of the rule -- in other words, we are inferring to be implemented for and we are (not incorrectly) deducing that . My branch rejects this because I specifically tried to disallow that. I am not entirely convinced that we should disallow this -- it's just that doesn't have a very natural analog in polonius (though you can make it make sense). In fact, the idea of is kind of useful, or could be, so it may be that we want to accept it. If we want to disallow this example, I think we'll have to extend NLL to have a similarly "graded" notion of . I imagine the way to do this would be to extend the set of elements to include "empty" elements in each universe we create, and then permit these empty elements get to all the "free regions" in the root universe.
On the latest nightly, passing causes and to produce . I think this is now purely a diagnostic issue, rather than a soundness issue.
Change:
// Allocate space and store the destructor pointer: let Result {bcx, val: llbox} = malloc_raw_dyn(bcx, ptr_llty, t, size, llalign); <del> let dtor_ptr = GEPi(bcx, llbox, &[0u, abi::box_field_drop_glue]); </del> <ins> let dtor_ptr = GEPi(bcx, llbox, &[0u, abi::BOX_FIELD_DROP_GLUE]); </ins> let drop_glue_field_ty = type_of(ccx, ty::mk_nil_ptr(bcx.tcx())); let drop_glue = PointerCast(bcx, glue::get_drop_glue(ccx, ty::mk_uniq(bcx.tcx(), t)), drop_glue_field_ty);

Discussion:
There are three versions of these layouts for functions, traits, and slices, but the compiler relies on these being the same. We should replace them with a single layout: and or something. While we're at it, we should probably find uses of len/length names in the DST code and replace it with something more generic.
I merged the constants. Could you elaborate on the length names? Are there more constants like these?
What still needs to be done here, if anything?
Looks done.
Change:
<ins> warning: function cannot return without recursing --> $DIR/multiple-defining-usages-in-body.rs:4:1 | LL | fn foo<T: Trait, U: Trait>() -> impl Trait { | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ cannot return without recursing LL | LL |     let a: T = foo::<T, U>(); |                ------------- recursive call site | = help: a `loop` may express intention better if this is on purpose = note: `#[warn(unconditional_recursion)]` on by default error: concrete type differs from previous defining opaque type use --> $DIR/multiple-defining-usages-in-body.rs:6:16 | LL |     let a: T = foo::<T, U>(); |                ^^^^^^^^^^^^^ expected `U`, got `T` | note: previous use here --> $DIR/multiple-defining-usages-in-body.rs:9:16 | LL |     let _: T = foo::<U, T>(); |                ^^^^^^^^^^^^^ error: aborting due to previous error; 1 warning emitted </ins>

Discussion:
The following code: used to incorrectly compile but now correctly errors, we should add a test to ensure this doesn't regress. cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // run-rustfix #[allow(dead_code)] enum Demo { A = 1, B == 2 //~ ERROR unexpected `==` //~^ expected item, found `==` } 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. If you cannot produce a minimal reproduction case (something that would work in isolation), please provide the steps or even link to a repository that causes the problematic output to occur. --Given the following code: The current output is: <!-- The following is not always necessary. --Ideally the output should suggest replacing the with where appropriate as the suggestion for incorrect usage of in place of already exist. <!-- If the problem is not self-explanatory, please provide a rationale for the change. --<!-- If dramatically different output is caused by small changes, consider also adding them here. 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. The output might also be different depending on the Edition. --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Change:
<ins> // ignore-tidy-trailing-newlines // pretty-compare-only /* */ </ins>  No newline at end of file

Discussion:
Note: missing newline after is essential. <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
I've not been able to reproduce this on the latest nightly, I've bisected it to have been fixed in 2020-07-15 (report used 2020-07-11), probably by ; I've filed with a regression test.
Me neither.
Change:
fcx.resolve_generator_interiors(def_id); for (ty, span, code) in fcx.deferred_sized_obligations.borrow_mut().drain(..) { <ins> let ty = fcx.normalize_ty(span, ty); </ins> fcx.require_type_is_sized(ty, span, code); } fcx.select_all_obligations_or_error();

Discussion:
does not build on the current nightly because the compiler is unable to infer that a type is . This is a regression in the latest nightly. The line that errors is . Error message: Relevant commits: cc rust-lang-nursery/futures-rs
Minimized example without and external dependencies: .
Possibly caused by cc
Enabling the feature fixes this, so this is being caused by the gate .
Perhaps do I need some normalization before doing deferred ness checking?
triage. This is now a stable-to-beta regression. P-high.
assigning to to either r+ PR , come up with a new fix, or delegate those options to someone else.
Change:
<ins> macro_rules! foo { ($ty:ty) => { fn foo(_: $ty, _: $ty) {} } } foo!(_); //~^ ERROR the placeholder `_` is not allowed within types on item signatures for functions 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. --<!-- 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
Probably just worth ignoring placeholder suggestions if they are coming from a different span ctxt than the fn -- either that, or logic to detect reuses of the same or something. Anyways, I think this is minimal: But I can't test it since I'm on my laptop.
Yeah can confirm this also triggers the debug assertion ^
Change:
_5 = ((_2 as Break).0: std::result::Result<std::convert::Infallible, i32>); StorageLive(_6); _6 = _5; <del> _12 = move ((_5 as Err).0: i32); </del> <ins> _12 = ((_5 as Err).0: i32); </ins> _0 = Result::<i32, i32>::Err(_12); StorageDead(_6); StorageDead(_2);

Discussion:
Right: Wrong: The first argument to is partially moved. GVN causes the second argument to use the partially moved value:
I can't provoke the miscompilation on beta using this example (just had to replace with to make it build), so I don't think there's any need to rush to fix this. (Some part of GVN is used in the beta that's about to become stable, but it looks like it doesn't have this bug in it)
Cc
WG-prioritization assigning priority (). label -I-prioritize +P-medium
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. #![feature(untagged_unions)] use std::cell::Cell; use std::ops::Deref; use std::mem::ManuallyDrop; union Wrap<T> { x: ManuallyDrop<T> } impl<T> Drop for Wrap<T>  { fn drop(&mut self) { unsafe { std::ptr::drop_in_place(&mut *self.x as *mut T); } } } impl<T> Wrap<T> { fn new(x: T) -> Self { Wrap { x: ManuallyDrop::new(x) } } } impl<T> Deref for Wrap<T> { type Target = T; #[inline] fn deref(&self) -> &Self::Target { unsafe { &self.x } } } struct C<'a>(Cell<Option<&'a C<'a>>>); impl<'a> Drop for C<'a> { fn drop(&mut self) {} } fn main() { let v : Wrap<C> = Wrap::new(C(Cell::new(None))); v.0.set(Some(&v)); //~ ERROR: `v` does not live long enough } </ins>

Discussion:
So it turns out that is a problem: The following code should be rejected by dropck, but . This is a nightly-only (because implementing for unions is unstable) soundness issue. I need unsafe code to exploit it, but above should be a perfectly safe to use type.
regression.
Not without guarantees on union validity :) Remember how third parties can legally write garbage into that's not a valid ? This means neither deref nor drop are safe operation in that interpretation.
No, that's not at all what I was saying. We were discussing basic layout invariants. These are invariants the compiler knows about and exploits for enum layout optimizations; violating them is insta-UB. For example, a reference must be non-NULL and aligned. Even a reference being valid is already not covered here as it cannot expressed in terms of just its bit pattern. However, for private fields, types may have arbitrary additional invariants. I hope we agree that the layout invariant for is simple: Just looking at the type , the only layout invariants we have is that none of the fields can be undef and that the first field must not be NULL. Still, a third party cannot legally write any garbage conforming with these invariants into those fields, like setting to ! Doing this is not insta-UB, but can easily lead to UB on the next call to . This is an example for an extra invariant that the compiler does not know about, that the data structure upholds through privacy and that unsafe code in this module can hence rely on. works the same way, its only field is private for this very reason.
Answered in to avoid offtopic here.