jiebi/CodeConvo huggingface dataset:
Change:
place_a: &Place<'tcx>, place_b: &Place<'tcx>, ) -> PlaceAncestryRelation { <del> // If Place A and Place B, don't start off from the same root variable, they are divergent. </del> <ins> // If Place A and Place B don't start off from the same root variable, they are divergent. </ins> if place_a.base != place_b.base { return PlaceAncestryRelation::Divergent; }

Discussion:
<details</summary</details<!-- 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 will try to reduce this to an MCVE.
Changing to appears to avoid the ICE, so that may be a useful place to focus.
Minimized it down to 60 lines without any dependencies. Maybe it can be minimized further but it's getting really hard. I've also left a few comments to say what's going on. <details<summary"Minimized" </summary</details
This appears to have regressed in Rust 1.64
This continues to ICE on beta and nightly
I bisected the regression, here is the output of : searched nightlies: from nightly-2022-06-24 to nightly-2022-08-05 regressed nightly: nightly-2022-07-14 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.4</summaryHost triple: x86_64-pc-windows-msvc Reproduce with: </details
Out of these seems the most likely, cc
Zooming onto changeset.
Found MVCE: <details<summaryOutput from Rust Playground</summary</details
Change:
<del> Subproject commit 3dfd4d93fa013e1c0578d3ceac5c8f4ebba4b6ec </del> <ins> Subproject commit 9ad24035fea8d309753f5e39e6eb53d1d0eb39ce </ins>

Discussion:
Our CI system building artifact for aarch64 with the release of Rust 1.65 I tried to reduce the bug a bit: dependencies Build with (same with ) Since Rust 1.65, we get this error: Can still be reproduced in nightly
I wasn't able to reproduce this (on either stable or nightly).
You're right, trying in a fresh project i couldn't reproduce. I realized the original also contained a that was also necessary I edited the original description to add Thanks for looking into this.
Also, contrary to what i wrote initially, the bug appeared first in 1.65 (and not 1.64)
Thanks, I can reproduce the issue now. Reduced test case:
Upstream issue:
The upstream issue appears to be fixed. What needs to be done now to apply this fix?
I can still reproduce this on 1.68.0-nightly ( 2022-12-15).
Can confirm that the issue still exists.
New upstream issue:
Change:
thread 'main' panicked at $DIR/test-panic-abort-nocapture.rs:33:5: <del> assertion failed: `(left == right)` left: `2`, right: `4` </del> <ins> assertion `left == right` failed left: 2 right: 4 </ins> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread 'main' panicked at $DIR/test-panic-abort-nocapture.rs:27:5: <del> assertion failed: `(left == right)` left: `2`, right: `4` </del> <ins> assertion `left == right` failed left: 2 right: 4 </ins> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace testing321

Discussion:
The custom message in macro is shown right after the . This is hard to read because the value strings could be very long. I think it is better to print the custom message (if available) on a separate line. The above (playground) prints this: Note that custom message and the location in source are still on the same line <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I will try it. claim
Note that the linked PR, , has a lot of review comments. I think rebasing that PR and addressing the comments would already be very close to landing this change.
(taking over due to inactivity) claim
:tada: Horray! It only took 548 days (1.5+ years) since I created on Feb 14th, 2022. Numerous commits. Tens of people. 4 PRs... 100s of files. All to change a few lines of output :) Special thanks to for all the support!
Change:
<ins> error[E0726]: implicit elided lifetime not allowed here --> $DIR/return-not-existing-pair.rs:12:20 | LL | impl<'a, 'b, T, U> MyTrait<T> for U { |                    ^^^^^^^^^^ expected lifetime parameters | help: indicate the anonymous lifetimes | LL | impl<'a, 'b, T, U> MyTrait<'_, '_, T> for U { |                            +++++++ error[E0412]: cannot find type `ConnImpl` in this scope --> $DIR/return-not-existing-pair.rs:8:48 | LL |     async fn foo(&'a self, key: &'b T) -> (&'a ConnImpl, &'b T); |                                                ^^^^^^^^ not found in this scope error[E0186]: method `foo` has a `&self` declaration in the trait, but not in the impl --> $DIR/return-not-existing-pair.rs:14:5 | LL |     async fn foo(&'a self, key: &'b T) -> (&'a ConnImpl, &'b T); |     ------------------------------------------------------------ `&self` used in trait ... LL |     async fn foo(_: T) -> (&'a U, &'b T) {} |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `&self` in impl error[E0308]: mismatched types --> $DIR/return-not-existing-pair.rs:14:42 | LL |     async fn foo(_: T) -> (&'a U, &'b T) {} |                                          ^^ expected `(&U, &T)`, found `()` | = note:  expected tuple `(&'a U, &'b T)` found unit type `()` error: aborting due to 4 previous errors Some errors have detailed explanations: E0186, E0308, E0412, E0726. For more information about an error, try `rustc --explain E0186`. </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
cc
This brings up the question again with whether or not we should just feed itemname for RPITITs. I can't recall the other issues where this was a problem, but perhaps we should just do that and revert all the previous mitigations we introduced due to the fact that itemname is missing for RPITITs.
Just pushed a fix, I think you were always right about not feeding item_name, whenever you try to call it for RPITITs we should have never tried because the message we are trying to fill won't make any sense.
Change:
<ins> // Copyright 2014 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. // Issue #6233 // xfail-fast feature doesn't work #[feature(thread_local)]; #[allow(dead_code)]; static SIZE: uint = 1 << 23; #[thread_local] static FOO: [u8, .. SIZE] = [0, .. SIZE]; fn main() {} </ins>

Discussion:
Linking with certain external libraries can inflate the required amount of thread local storage to astronomical proportions. When the Rust runtime tries to create its threads, it requests a stack size independent of the TLS size, which can lead to pthreadcreate() failing with EINVAL when the stack size is smaller than the TLS size. This was apparently an issue for the Go runtime as well (). A potential workaround is to add statictls_size (+ possibly a guard page) to the requested stack size, but it's arguably a bug in glibc that TLS comes out of the requested stack, instead of being to it. This solution is also admittedly not very pleasing...
I made a mistake. The workaround should actually be to add _pthreadgetminstack(&attr) to the requested size in It's still not very pleasing.
This is the bug in glibc
Still relevant, but it's an upstream bug. Removing E-easy
Triage: we still call without adjusting for so I assume that the work-around hasn't been implemented, and the upstream bug is still open (and without activity for more than 3 months).
Triage: still a bug even with the pure Rust runtime. With it crashes with: and without that it runs fine. I'll attempt to fix it now.
(The above crash appears to not happen on Mac OSX; I'm on Linux.) I opened ; but I don't think that work-around is complete enough to close this.
My patch caused people linking errors ( is apparently not in all versions of glibc (works in 2.17, fails with 2.13), being a private function), so I'm reverting it in .
Change:
infer::HigherRankedType, tcx.fn_sig(impl_m.def_id).instantiate_identity(), ); <del> let unnormalized_impl_fty = Ty::new_fn_ptr(tcx, ty::Binder::dummy(unnormalized_impl_sig)); </del> let norm_cause = ObligationCause::misc(impl_m_span, impl_m_def_id); let impl_sig = ocx.normalize(&norm_cause, param_env, unnormalized_impl_sig);

Discussion:
The lint is triggered by the following code (from , cc : In the environment , the type surprisingly requires for well-formedness (see ), but this constraint is not used in implied bounds, so I believe it can't be exploited for unsoundness. The lint was upgraded to deny-by-default in the current beta (1.68.0-beta.5 2023-02-15 ). So this counts as regression? cc label C-bug T-types T-compiler regression-from-stable-to-beta
:facepalm: I think this is due to us preferring param-env candidates for .
So the issue here is that requires . We try to prove that in the hybrid param-env of the impl's WC + trait method's WC, being after substituting . Due to some frustrating precedence rules around candidate assembly in the trait solver, we try to match against the param-env candidate and get . We also assemble a built-in sized bound, but always prefer the param-env candidate over that. That requires us to prove , which is not known to be true in the hybrid param-env, triggering the lint.
I wonder if we could get away with not checking , but just the implied lifetime bounds or something :thinking:
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Been thinking about this a little bit. One thought I had was to check that the impl method is WF given only the trait method, but I think that would break this example: I wonder if we could get away with not checking WF(return-type), but just the implied lifetime bounds or something This is annoying difficult, because it's not straightforward to get "just the implied lifetime bounds" of a type. I'm playing around with using and filtering outlives bounds, but that can generate more predicates (which, I thought we had somewhere a function that recurses though those). We'll see if this works...
Change:
<ins> // Copyright 2015 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. #[derive(PartialEq)] struct Slice { slice: [u8] } fn main() {} </ins>

Discussion:
Fedora 21 x86_64, rustc 1.0.0-nightly ( 2015-03-22) (built 2015-03-23). I hit an assertion when compiling cuviper/rust-git-fs I haven't tried to reduce it yet. Stack trace from coredumpctl:
I narrowed this down to my , where a is indexed by a . I can reproduce the crash with this smaller example: If I convert to a first, then all is fine.
Another example is:
Does not seem to affect beta or nightly. Marking as E-needstest
I'll add regression tests for these examples right now
Change:
<ins> // This checks that function pointer signatures containing &mut T types // work in a constant context: see issue #114994. // // check-pass const fn use_const_fn(_f: fn(&mut String)) { () } const fn get_some_fn() -> fn(&mut String) { String::clear } const fn some_const_fn() { let _f: fn(&mut String) = String::clear; } fn main() {} </ins>

Discussion:
Proposing to extract this from . The following examples shouldn't error: While this has been considered part of for a while, it's also been acknowledged as a bug and suggested by to address separately ahead of stabilizing . Indeed it's surprising for users that this would count as handling a mutable reference in const contexts. See: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Cc Fixing this requires changing to skip traversing things inside function pointers. I'm not sure what the best way to achieve that is.
claim
Is there any reason returning a function trait object (e.g. , , etc.) does not work? It works with the feature, but IMO it should have been pulled out like the function pointers. For example this does not compile:
We didn't exhaustively look through all cases that we can exempt here. Anyway, is on the , so this question will be moot soon. :)
Change:
// If this file descriptor is indeed guessed to be a tty, then go ahead // with attempting to open it as a tty. let handle = UvHandle::alloc(None::<TtyWatcher>, uvll::UV_TTY); <ins> let mut watcher = TtyWatcher { tty: handle, stream: StreamWatcher::new(handle), home: io.make_handle(), fd: fd, }; </ins> match unsafe { uvll::uv_tty_init(io.uv_loop(), handle, fd as libc::c_int, readable as libc::c_int) } { <del> 0 => { Ok(TtyWatcher { tty: handle, stream: StreamWatcher::new(handle), home: io.make_handle(), fd: fd, }) } </del> <ins> 0 => Ok(watcher), </ins> n => { <del> unsafe { uvll::free_handle(handle) } </del> <ins> // On windows, libuv returns errors before initializing the // handle, so our only cleanup is to free the handle itself if cfg!(windows) { unsafe { uvll::free_handle(handle); } watcher.tty = ptr::null(); } </ins> Err(UvError(n)) } }

Discussion:
I'm on OSX 10.8.4, x8664, latest Rust on master. And to head off any concerns about my file handle limits: I ran into this when stress-testing my web sockets library. After just a couple hundred connections, some connections were being refused at random. The only thing I could see was some output with saying . I've come up with a smaller test case that brings this out with some spectacular errors: Fails less often with 100-200 connections. The errors are different every time I run this with . Here's the end of one run: Another: Another: And lastly:
cc
Oh dear that's bad, thanks for the small issue! I will definitely investigate.
What is the result of though? Just calling is only the maximum file size (unless OSX is different).
you're right! So I set it to a higher value and things seem fine now. Sorry about that. Though, It's still a surprising way for the runtime to fail, and clearly something is still wrong there.
Despite OSX having small file descriptor limits, this is a serious bug that I'd like to address with the runtime. Something funny is going on.
With applied, I am unable to reproduce this on OSX. I am not convinced that it fixes anything, but I'm no longer seeing any scary assertions.
I take that back, I was using , not (silly me)
I attempted to debug this issue on linux, and I quickly ran into two problems. The first is an assertion fixed by , and the other is filed as Sadly none of this seems related to the assertions on OSX, so I'll continue to investigate there. If only OSX still had valgrind...
Change:
<ins> // Copyright 2016 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. // Check that constant ADTs are translated OK, part k of N. #![feature(slice_patterns)] enum Bar { C } enum Foo { A {}, B { y: usize, z: Bar }, } const LIST: [(usize, Foo); 2] = [ (51, Foo::B { y: 42, z: Bar::C }), (52, Foo::B { y: 45, z: Bar::C }), ]; pub fn main() { match LIST { [ (51, Foo::B { y: 42, z: Bar::C }), (52, Foo::B { y: 45, z: Bar::C }) ] => {} _ => { // I would want to print the enum here, but if // the discriminant is garbage this causes an // `unreachable` and silent process exit. panic!("trivial match failed") } } } </ins>

Discussion:
This code () gives me a segfault on the current beta: I've reduced it as much as I can, even removing the constructor on the enum causes it to work. I expect the output to be (which it is on stable), but instead I get
Appears to be broken on nightly as well - I get a stack overflow on x86_64 darwin.
FWIW, I don't get a segfault on beta or nightly with the playpen, I just get this output for both:
The stackoverflow on x86_64 darwin goes away for me on any .
This strongly reminds me of and .
Change:
fn clean(&self, cx: &mut DocContext<'_>) -> Variant { match self { hir::VariantData::Struct(..) => Variant::Struct(self.clean(cx)), <del> hir::VariantData::Tuple(..) => { Variant::Tuple(self.fields().iter().map(|x| x.ty.clean(cx)).collect()) } </del> <ins> // Important note here: `Variant::Tuple` is used on tuple structs which are not in an // enum (so where converting from `ty::VariantDef`). In case we are in an enum, the kind // is provided by the `Variant` wrapper directly, and since we need the fields' name // (even for a tuple struct variant!), it's simpler to just store it as a // `Variant::Struct` instead of a `Variant::Tuple` (otherwise it would force us to make // a lot of changes when rendering them to generate the name as well). hir::VariantData::Tuple(..) => Variant::Struct(self.clean(cx)), </ins> hir::VariantData::Unit(..) => Variant::CLike, } }

Discussion:
Rustdoc should expose doc comments written on tuple fields: Tagging based on conversation on IRC.
This issue also applies to tuple variant fields:
It promises to be very interesting from a design point of view. We'll to think about how to render this nicely.
Change:
.all(|t| trivial_dropck_outlives(tcx, t)), ty::TyAdt(def, _) => { <del> if def.is_union() { // Unions never have a dtor. true } else if Some(def.did) == tcx.lang_items().manually_drop() { </del> <ins> if Some(def.did) == tcx.lang_items().manually_drop() { </ins> // `ManuallyDrop` never has a dtor. true } else { // Other types might. Moreover, PhantomData doesn't // have a dtor, but it is considered to own its <del> // content, so it is non-trivial. </del> <ins> // content, so it is non-trivial. Unions can have `impl Drop`, // and hence are non-trivial as well. </ins> false } }

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.
Change:
<del> #![crate_type = "staticlib"] extern "C" { fn this_symbol_not_defined(); } #[no_mangle] pub extern "C" fn foo() { unsafe { 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.