jiebi/CodeConvo huggingface dataset:
Code change:
<ins> // check-pass #![deny(unused_lifetimes)] trait Trait2 { type As; } // we should not warn about an unused lifetime about code generated from this proc macro here #[derive(Clone)] struct ShimMethod4<T: Trait2 + 'static>(pub &'static dyn for<'s> Fn(&'s mut T::As)); pub fn main() {} </ins>

Related discussion:
text: <!-- 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 requires debug assertions <!-- 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 --
lol, nightly emits this:D : another one from
any updates? :upsidedownface:
claim I think I got a fix :slightlysmilingface:
Error: Parsing assign command in failed: ...' claim' ' I think I'... Please file an issue on GitHub at if there's a problem with this bot, or reach out on on Zulip.
claim
Code change:
<ins> error: expected trait bound, found `impl Trait` type --> $DIR/issue-102182-impl-trait-recover.rs:1:11 | LL | fn foo<T: impl Trait>() {} |           ^^^^^^^^^^ not a trait | help: use the trait bounds directly | LL - fn foo<T: impl Trait>() {} LL + fn foo<T: Trait>() {} | error: aborting due to previous error </ins>

Related discussion:
text: When writing the current error is "expected one of these tokens", without any attempt to recover the parse. It should instead be closer to: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
What do you expect the suggestion from this code? here is a valid identifier, "expected one of these tokens" comes when the second identifier comes.
I think this case should remain as is. in particular is a shame because it is a valid type for the parser, but not a valid trait, and newcomers might not yet have a mental model for the distinction. I would say, when parsing a trait, if it can't be parsed, then try to parse a type in a snapshot (like we do in other parts of the parser), and if successful, emit a targeted error (trait expected but found type).
claim
Code change:
/// # Examples /// /// ```no_run <del> /// #![feature(buffered_io_capacity)] </del> /// use std::io::{BufReader, BufRead}; /// use std::fs::File; ///

Related discussion:
text: adds methods to and . Unresolved questions:
Can I nominate this for stabilization? It's a straightforward API with no real alternatives possible, and I had a real-world use case for it recently.
CC --^?
fcp merge
Team member has proposed to merge this. The next step is review by the rest of the tagged team members: [x] [ ] [x] [x] [ ] No concerns currently listed. Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up! See for info about what commands tagged team members can give me.
:bell: This is now entering its final comment period, as per the . :bell:
The final comment period, with a disposition to merge, as per the , is now complete. As the automated representative of the governance process, I would like to thank the author for their work and everyone else who contributed. The RFC will be merged soon.
Code change:
- it is bound as an associated type, e.g. `impl<T, U> SomeTrait for T where T: AnotherTrait<AssocType=U>` <ins> Any unconstrained lifetime parameter of an `impl` is not supported if the lifetime parameter is used by an associated type. </ins> ### Error example 1 Suppose we have a struct `Foo` and we would like to define some methods for it.

Related discussion:
text: As it is currently written, E0207 talks entirely about type parameters. Now that const parameters also need to constrain implementations (under the same rules described for types), they also need to be mentioned in the error explanation. Since other items don't require const parameters to be used at all, we might also want to specifically call out this difference here. Furthermore, E0207 triggers if you use an unconstrained lifetime in an associated type, and this is completely unspecified by the error as well. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
= help: the trait `Sized` is not implemented for `[u8]` = note: all local variables must have a statically known size = help: unsized locals are gated as an unstable feature <ins> help: consider borrowing here | LL |     let _foo: &[u8] = *foo; |               + </ins> error: aborting due to 3 previous errors

Related discussion:
text: I tried compiling this code: which resulted in the following output of rustc: So the compiler says So I tried adding a borrow and recompiling the code: which resulted in: so the compiler says and so I'm stuck in a loop. The compiler can't decide whether I should borrow or not. As a newbie to Rust, this is very frustrating and the opposite of helpful, it just confuses me further. Please fix this indecisiveness :) :
For reference, what you likely want to do is one of the following which means they cannot be the type of a local binding. You can give a binding a slice type (), because that's morally equivalent to a pointer (with sizing info), which has a compile time determined size, as all borrows are .
Current output: After :
Code change:
element_ty } None => { <ins> // Attempt to *shallowly* search for an impl which matches, // but has nested obligations which are unsatisfied. for (base_t, _) in self.autoderef(base.span, base_t).silence_errors() { if let Some((_, index_ty, element_ty)) = self.find_and_report_unsatisfied_index_impl(expr.hir_id, base, base_t) { self.demand_coerce(idx, idx_t, index_ty, None, AllowTwoPhase::No); return element_ty; } } </ins> let mut err = type_error_struct!( self.tcx.sess, expr.span,

Related discussion:
text: I tried this code (): I expected to see this happen: rustc outputs an error saying that I need to add the and traits on . Instead, this happened: which is jarring to see, and unhelpful, because HashMap does support Index, but only with particular trait bounds on . <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
The reduced case: works as expected, perhaps it is caused when the implementer is not from the local crate?
claim
Code change:
.map(|param| tcx.type_of(param.def_id)) // This is no generic parameter associated with the arg. This is // probably from an extra arg where one is not needed. <del> .unwrap_or(tcx.types.err) </del> <ins> .unwrap_or_else(|| { tcx.sess.delay_span_bug( DUMMY_SP, &format!( "missing generic parameter for `AnonConst`, parent {:?}", parent_node ), ); tcx.types.err }) </ins> } else { tcx.sess.delay_span_bug( DUMMY_SP,

Related discussion:
text: results in an ICE (): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
LL | use V; |     ^ ambiguous name | <del> = note: ambiguous because of multiple potential import sources </del> <ins> = note: ambiguous because of multiple glob imports of a name in the same module </ins> note: `V` could refer to the variant imported here --> $DIR/issue-105069.rs:1:5 | LL | use self::A::*; |     ^^^^^^^^^^ <ins> = help: consider adding an explicit import of `V` to disambiguate </ins> note: `V` could also refer to the variant imported here --> $DIR/issue-105069.rs:3:5 | LL | use self::B::*; |     ^^^^^^^^^^ <ins> = help: consider adding an explicit import of `V` to disambiguate </ins> error: aborting due to previous error

Related discussion:
text: <!-- 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
`
label +S-bug-has-mcve
What is the expected output here? Can this actually compile, and if so, what does refer to?
Code change:
// (We do this separately from the above so that when the setup actually // happens we get some output.) // We re-use the `cargo` from above. <del> cargo.arg("--env"); </del> <ins> cargo.arg("--print-sysroot"); </ins> // FIXME: Is there a way in which we can re-use the usual `run` helpers? let miri_sysroot = if builder.config.dry_run {

Related discussion:
text: 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 compiler team prioritization.
Code change:
<ins> // ... continued from ./min-choice.rs // check-fail trait Cap<'a> {} impl<T> Cap<'_> for T {} fn type_test<'a, T: 'a>() -> &'a u8 { &0 } // Make sure we don't pick `'b`. fn test_b<'a, 'b, 'c, T>() -> impl Cap<'a> + Cap<'b> + Cap<'c> where 'a: 'b, 'a: 'c, T: 'b, { type_test::<'_, T>() // This should pass if we pick 'b. //~^ ERROR the parameter type `T` may not live long enough } // Make sure we don't pick `'c`. fn test_c<'a, 'b, 'c, T>() -> impl Cap<'a> + Cap<'b> + Cap<'c> where 'a: 'b, 'a: 'c, T: 'c, { type_test::<'_, T>() // This should pass if we pick 'c. //~^ ERROR the parameter type `T` may not live long enough } // We need to pick min_choice from `['b, 'c]`, but it's ambiguous which one to pick because // they're incomparable. fn test_ambiguous<'a, 'b, 'c>(s: &'a u8) -> impl Cap<'b> + Cap<'c> where 'a: 'b, 'a: 'c, { s //~^ ERROR captures lifetime that does not appear in bounds } fn main() {} </ins>

Related discussion:
text: The following code should pass regardless of the declaration order of lifetimes: This is related to but it's different in that we do have a lower bound region, , but we fail to recognize that because , which is responsible for calculating from , assumes that the outlive relation is a total order, which is not true. Here is the graph of : ! So we need an efficient algorithm that works for partial order relations, but the one that comes to mind is . The perf may not be really important here but I'm curious to see the alternatives. label C-bug T-compiler A-borrow-checker E-mentor E-help-wanted <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Here is the code of concern The code should calculate the from a set of universal regions (). The relations are encoded in and are guaranteed to be transitive and reflexive. The relation graph may have cycles and can be sparse. The goal here is to find a unique minimum choice that is known to be outlived by all other regions. If none can be found, the function returns . Regions that have cycles between them are considered equivalent so we can pick either one of them as a unique choice. e.g. , we can pick either one of as a minimum choice.
Code change:
let verbose = std::env::var("MIRI_VERBOSE") .map_or(0, |verbose| verbose.parse().expect("verbosity flag must be an integer")); <del> // phase_cargo_miri sets the RUSTDOC env var to ourselves, so we can't use that here; // just default to a straight-forward invocation for now: let mut cmd = Command::new("rustdoc"); </del> <ins> // phase_cargo_miri sets the RUSTDOC env var to ourselves, and puts a backup // of the old value into MIRI_ORIG_RUSTDOC. So that's what we have to invoke now. let rustdoc = env::var("MIRI_ORIG_RUSTDOC").unwrap_or("rustdoc".to_string()); let mut cmd = Command::new(rustdoc); </ins> let extern_flag = "--extern"; let runtool_flag = "--runtool";

Related discussion:
text: Currently we do ensure on CI that works, but doctests are enabled as I couldn't figure out how to get this to work within bootstrap. However, that has let slip through. So ideally we can figure out these bootstrap issues and test rustdoc inside on rustc CI.
Here's what currently happens: shows a similar error. So... probably we're using the wrong rustdoc? I assume it's the bootstrap rustdoc, if that's a thing? I can't even see a rustdoc being built in the build log. We want the rustdoc that is produced by stage 0 here, since we are testing the Miri produced by stage 0. How do we get that? Cc
looks to be the reason we're running a random rustdoc here. I suspect we'll need to thread through a custom bootstrap env variable, since IIRC there's no RUSTDOC_WRAPPER that miri can use to thread state. Alternatively it might work to adjust miri such that it remembers which toolchain is running earlier, but I suspect that'll be harder. As-is though it's almost certainly semi-broken for any Rust user doing something like presumably, where their default toolchain isn't nightly?
It seems to be working, AFAIK rustup ensures that nested calls use the -specified toolchain. Or maybe we are just lucky... But yes we should in the outermost wrapper, determine which rustdoc cargo would invoke using the same logic as cargo store that in a miri-private env var invoke that in I assume however we'll also need further changes in how bootstrap invokes cargo-miri to tell it where the right rustdoc lives? Currently we're not even building rustdoc so something surely needs to change in bootstrap. I see this snippet a few times, is that all we need?
Yeah, I'd expect that to be enough to start with at least. Also potentially relevant: If we're already using somewhere in there (we should be, probably?) then that should already get mostly setup, see here: ,
We do that already: Unless you are trying stage 0, you should be able to see rustdoc compilation in the build logs.
This is stage 0. It should still have to build rustdoc, stage 0 Miri needs stage 0 rustdoc (not bootstrap rustdoc) for its doctests.
Code change:
let verbose = std::env::var("MIRI_VERBOSE") .map_or(0, |verbose| verbose.parse().expect("verbosity flag must be an integer")); <del> // phase_cargo_miri sets the RUSTDOC env var to ourselves, so we can't use that here; // just default to a straight-forward invocation for now: let mut cmd = Command::new("rustdoc"); </del> <ins> // phase_cargo_miri sets the RUSTDOC env var to ourselves, and puts a backup // of the old value into MIRI_ORIG_RUSTDOC. So that's what we have to invoke now. let rustdoc = env::var("MIRI_ORIG_RUSTDOC").unwrap_or("rustdoc".to_string()); let mut cmd = Command::new(rustdoc); </ins> let extern_flag = "--extern"; let runtool_flag = "--runtool";

Related discussion:
text: (...) ah fun, so if we invoke RUSTDOC we'll actually invoke bootstrap's rustdoc wrapper. We'll have to see if having both Miri and that wrapper around will work.^^
Never mind, that was for a build. For stage 0 this doesn't happen. I don't think this can work though... The staging with Miri is a bit weird; we need a stage 1 std as well for our stage 0 tests. Specifically we need a host sysroot that was built with a compiler that "is the same as" Miri, i.e. that is fully compatible. (The is wrong, it's not the compiler that built Miri.) This was needed to make build scripts and proc macros work in .
Yes, and if you want to use the actual rustdoc without wrapper, you can invoke . I tried using env instead of plain "rustdoc" and this is the output:
I had to manually pass from the cargo miri test caller; it turns out we are not passing it by default (or it somehow gets removed later?). Anyway, this is how I tested it:
Yeah currently this does not work due to But you have already come closer than I did. :) Was that with or stage 1? Maybe is ?
I guess that needs to be resolved first before we enable doctests on cargo miri test ? It was stage 1. Yeah, it seems like.
Yes. must continue working. I don't want to always build rustc twice when working on Miri in the tree.^^ But if necessary we could enable doc-tests only for higher stages... that would still be better than the status quo.
Code change:
<ins> // unit-test: ConstProp // compile-flags: -O // Regression test for https://github.com/rust-lang/rust/issues/118328 #![allow(unused_assignments)] struct SizeOfConst<T>(std::marker::PhantomData<T>); impl<T> SizeOfConst<T> { const SIZE: usize = std::mem::size_of::<T>(); } // EMIT_MIR overwrite_with_const_with_params.size_of.ConstProp.diff fn size_of<T>() -> usize { // CHECK-LABEL: fn size_of( // CHECK: _1 = const 0_usize; // CHECK-NEXT: _1 = const _; // CHECK-NEXT: _0 = _1; let mut a = 0; a = SizeOfConst::<T>::SIZE; a } fn main() { assert_eq!(size_of::<u32>(), std::mem::size_of::<u32>()); } </ins>

Related discussion:
text: Fuzzer generated MIR, reduced, and UB-free under Miri (for real this time :sweatsmile:) Segfaults with enabled: , which is a valid pointer, somehow got propagated as 0: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
That seems undesirable. Is there a surface Rust program that can produce this MIR? Asking primarily for prioritization purposes.
WG-prioritization assigning priority (). label -I-prioritize +P-medium
Minimized test case:
Here's an example using stable surface syntax (). Seems to have been introduced in 1.70, with in particular.
Nevermind seems like I was wrong. <details</details
It's not an LLVM miscompilation, the code is already by the time it goes to LLVM. With So it's defiantly happening in MIR ConstProp
The problem seems to be that when running on the statement , the frames arn't updated, so when it runs on , it thinks is their for local . , on to add logging and test. ()
claim
Cc
Code change:
<del> // no-prefer-dynamic </del> #![feature(unsized_tuple_coercion)] static mut DROP_RAN: isize = 0;

Related discussion:
text: Right now on our bots we're basically in a state where if valgrind rpass tests are compiled dynamically they will all fail, but when compiled statically they will pass. I'm not really sure what's going on unfortunately, but this is either a bug in valgrind or a bug with us, and we should know precisely what it is to ensure something more sinister isn't lurking. Some links: - first pass at linking tests statically, fixed - another pass at linking all tests statically
All the failures seem to be within platform’s dynamic loader. Here’s a few things to try: updating kernel+glibc to the most recent versions (4.4-ish and 2.23-ish, respectively) help? downgrading kernel+glibc to some older version help? non-linux/non-glibc work correctly?
Any news/changes on this one ?
Code 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. // Test that moves of unsized values within closures are caught // and rejected. fn main() { (|| box *[0u].as_slice())(); //~^ ERROR cannot move a value of type [uint] } </ins>

Related discussion:
text: Compilation backtrace Version Seems to be very similar to and , but the difference is trying to send the value over a channel (removing this gives a "cannot move a value of type [u8]: the size of [u8] cannot be statically determined)
Just to update after the 0.12 release. I tried compiling the above example and am getting the same result (so this issue is still relevant).
Reduced test case: Something about the closure lets it get past type checking when it shouldn't.
This looks simple, I'll hopefully have a PR shortly.
Closed by
Code change:
struct GoodVoid(Void); fn main() { <del> let w = SingleUnused(42, [0, 1, 2, 3], "abc".to_string()); let _ = w.0; let _ = w.2; </del> <ins> let u1 = UnusedAtTheEnd(42, 3.14, [0, 1, 2, 3], "def".to_string(), 4u8); let _ = u1.0; let _ = UnusedJustOneField(42); let u2 = UnusedInTheMiddle(42, 3.14, "def".to_string(), 4u8, 5); let _ = u2.0; let _ = u2.3; </ins> <del> let m = MultipleUnused(42, 3.14, "def".to_string(), 4u8); </del> let gu = GoodUnit(()); let gp = GoodPhantom(PhantomData); let gv = GoodVoid(Void); <del> let _ = (gu, gp, gv, m); </del> <ins> let _ = (gu, gp, gv); </ins> }

Related discussion:
text: The idea of changing a field to unit type to preserve field numbering makes sense for fields in the middle of a tuple. However, if the unused field is at the end, or it's the only field, then deleting it won't affect field numbering of any other field. No response No response <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Code change:
let size = mem::size_of::<T>() .checked_mul(count) .expect("is_nonoverlapping: `size_of::<T>() * count` overflows a usize"); <del> let diff = if src_usize > dst_usize { src_usize - dst_usize } else { dst_usize - src_usize }; </del> <ins> let diff = src_usize.abs_diff(dst_usize); </ins> // If the absolute distance between the ptrs is at least as big as the size of the buffer, // they do not overlap. diff >= size

Related discussion:
text: In , it was uncovered that is making some rather strong assumptions: two s with different address but the same type must not overlap. Not only is this a scarily non-local safety invariant, it is also fundamentally incomaptible with some APIs that ought to be correct, as demonstrated by this snippet (thanks to and for help with working out the example): to see the issue: will duplicate parts of the memory range when there is overlap, which leads to double-drop (other parts of the memory range are just lost, leading to memory leaks, but that is not the main issue here). This is not itself a soundness issue as it requires unsafe code to trigger UB. But this likely reflects an unintended consequence of . This got stabilized in as part of That commit references and an RFC, but is not mentioned in either of them. was in Accept that is unsound and document "non-overlap" as part of the safety invariant. This seems very fragile. Make not misbehave on overlap, either by panicking or by only swapping the non-overlapping parts. Cc
was in , which was authored by a "Charlie Fan". This is probably
Cc
This makes the method sound, but it seems like there could be other seems-like-they-should-be-ok cell projections that break under this behavior.
I don't think so. This makes the function behave "strangely", but since no data is duplicated nor discarded, I think it is sound.
I share this hunch, although the code, out of nowhere, may look very contrived. Consider: So it seems like -king (at least for non- types) is the only option that would allow us too keep the structural property of s, which, imho, is a very intuitive programmer mindset (and thus, a mistake that many would do should they not know about this caveat), and so a quite important thing to preserve .
That is an example of the "strange" behavior not being the right thing for this code, but it is not an unsoundness of per se. Your unsafe code is simply making wrong assumptions about the functional behavior of . Current favors the first operand in case of overlap (according to documentation); unsafe code that incorrectly assumes it would favor the second operand would be equally wrong. I don't see a bug in either way. IMO it seems rather strange to only panic for non- types.