jiebi/CodeConvo huggingface dataset:
Change:
<ins> // run-pass #![allow(unused_must_use)] #![feature(unwind_attributes)] // Since we mark some ABIs as "nounwind" to LLVM, we must make sure that // we never unwind through them. // ignore-cloudabi no env and process // ignore-emscripten no processes // ignore-sgx no processes use std::{env, panic}; use std::io::prelude::*; use std::io; use std::process::{Command, Stdio}; #[unwind(aborts)] // FIXME(#58794) should work even without the attribute extern "C" fn panic_in_ffi() { panic!("Test"); } #[unwind(aborts)] extern "Rust" fn panic_in_rust_abi() { panic!("TestRust"); } fn test() { let _ = panic::catch_unwind(|| { panic_in_ffi(); }); // The process should have aborted by now. io::stdout().write(b"This should never be printed.n"); let _ = io::stdout().flush(); } fn testrust() { let _ = panic::catch_unwind(|| { panic_in_rust_abi(); }); // The process should have aborted by now. io::stdout().write(b"This should never be printed.n"); let _ = io::stdout().flush(); } fn main() { let args: Vec<String> = env::args().collect(); if args.len() > 1 { // This is inside the self-executed command. match &*args[1] { "test" => return test(), "testrust" => return testrust(), _ => panic!("bad test"), } } // These end up calling the self-execution branches above. let mut p = Command::new(&args[0]) .stdout(Stdio::piped()) .stdin(Stdio::piped()) .arg("test").spawn().unwrap(); assert!(!p.wait().unwrap().success()); let mut p = Command::new(&args[0]) .stdout(Stdio::piped()) .stdin(Stdio::piped()) .arg("testrust").spawn().unwrap(); assert!(!p.wait().unwrap().success()); } </ins>

Discussion:
I would expect the following code to abort, and never print : But instead, the attribute . Cc
That looks like a bug. cc
is just , and having in the testcase may create the wrong impression (i.e. this bug has nothing to do with FFI). Still, the attribute should either work and cause an abort or error as unapplicable.
I deliberately made it explicit, but sure, I can adjust the example.
Agreed that this just looks like a bug that needs to be fixed.
Change:
resume_arg, drop: _, } => { <ins> self.visit_operand(value, source_location); </ins> self.visit_place( resume_arg, PlaceContext::MutatingUse(MutatingUseContext::Store), source_location, ); <del> self.visit_operand(value, source_location); </del> } }

Discussion:
I tried this code: I expected to see see the output "Person is Mood", instead, I got a segfault: : <details<summaryBacktrace</summary<p</p</details
Heh, looks like my "fix" for the miscompilation I found while implementing this wasn't actually sufficient. Reduced to: Looking at the MIR, you can see: The first leads to , which stores the resume argument from in the generator state as and advances to the next state (discriminant 3). On the next call it resumes at , which doesn't store the resume argument in the state (it only moves it to ). Here, the argument should have ended up in the generator state as some field. It then sets the discriminant to 4 to resume at . The next call thinks is still live and uses it to call the function. MIR of (minus storage statements):
Hmm, on second thought, it seems weird that is not put in the generator state at all, I would expect the existing transform infrastructure to handle this. cc
Looking at the MIR generated for reduced test case we can see that the writes that should have been to is instead done to the generator : So this seems to be a problem in MIR construction.
Hmm: I assume this isn't correct anymore? ( probably should have been replaced with the newly introduced field in ? )
Well that would explain why the MIR looks wrong.
I suspect this is because doesn't consider terminators as writes.
Thought I'd fix the printing real quick I'll look into the real bug tomorrow or some time next week, but the pass does indeed look wrong now.
I don't know much about rustc internals but it seems these places seem relevant somehow?
Yes, that's the issue I was referring to.
This patch makes the generator layout look more reasonable (actually containing slots for the s), but doesn't fix the crash. In fact, it makes the test miscompile too:
Well, afaict the main issue here is that the transformation which replaces the s with generator struct accesses is run before creating the actual resume function which emits the store of the resume argument to a local which should've been replaced. This happens: before this: I've tested the follwing patch (Hacky, we probably want to use the somehow): (Most of the diff is not relevant to the patch, contains the fix).

And it produces correct MIR code: EDIT: The original code contains a logic bug, every loop iteration a new empty is created , which is probably not intended, instead moving that binding to the outer scope should "fix" it. EDIT: And passes too. EDIT: Also I've just stupidly realized that the unwrap for should probably be avoided too since a local may not live across a suspension point.
I probably would have noticed that if not for that pesky segfault
That's a great start! I've opened a fix (+ cleanup + more docs) based on the same idea in
Change:
candidate_field: &ty::FieldDef, subst: SubstsRef<'tcx>, mut field_path: Vec<Ident>, <ins> id: DefId, </ins> ) -> Option<Vec<Ident>> { debug!( "check_for_nested_field(span: {:?}, candidate_field: {:?}, field_path: {:?}",

Discussion:
Lets consider the following code () : Here, we try to access a property on an object of type . Up to the 1.50 version, the error message was the following : However, since Rust 1.51 and onward, the diagnostic message changed to this: While there is indead a property on the struct, this can't be accessed like that, applying the compiler suggestion implies making the property of public, which is not possible. The compiler should not look at non- properties when searching for properties with a matching name for diagnostic purposes. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
label +A-diagnostics
Related issue:
Change:
<ins> // build-pass #![feature(const_trait_impl)] trait Func<T> { type Output; fn call_once(self, arg: T) -> Self::Output; } struct Closure; impl const Func<&usize> for Closure { type Output = usize; fn call_once(self, arg: &usize) -> Self::Output { *arg } } enum Bug<T = [(); Closure.call_once(&0) ]> { V(T), } 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. --code from glacier/fixed/-1.rs <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
This is caused by , when we try to resolve the instance for a trait fn we use receiver substs from the , which don't match with the generic params the associated fn expects. This happens when we change the of the callee. What was the intent of that change?
I didn't see the call to after that. I think I basically wanted to replicate the behavior of , when I didn't know that it is already being done. A trivial fix is to just leave that match arm empty.
I tried that, I also tried to just use the identity substs, in which case the resolution succeeds. But in both cases we get another ICE later during monorphization (which I'm not familiar with). This is the backtrace: What does correspond to? Where is the instance for that created and why isn't it local? Could this be related to the changes in your PR? cc
I have no idea what that ICE means. I haven't touched code in that backtrace.
That ICE resulted from some debugging code I had included, sorry for the confusion.
Change:
<ins> error[E0277]: the trait bound `impl Trait<<u32 as std::ops::Add>::Output>: Trait<u32>` is not satisfied --> $DIR/issue-58344.rs:42:13 | LL | ) -> Either<impl Trait<<u32 as Add<u32>>::Output>, impl Trait<<u32 as Add<u32>>::Output>> { |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Trait<u32>` is not implemented for `impl Trait<<u32 as std::ops::Add>::Output>` | = note: the return type of a function must have a statically known size error[E0277]: the trait bound `impl Trait<<u32 as std::ops::Add>::Output>: Trait<u32>` is not satisfied --> $DIR/issue-58344.rs:42:52 | LL | ) -> Either<impl Trait<<u32 as Add<u32>>::Output>, impl Trait<<u32 as Add<u32>>::Output>> { |                                                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ the trait `Trait<u32>` is not implemented for `impl Trait<<u32 as std::ops::Add>::Output>` | = note: the return type of a function must have a statically known size error: aborting due to 2 previous errors For more information about this error, try `rustc --explain E0277`. </ins>

Discussion:
Using a generic function to "converge" two into when T is an associated type for another trait causes the following error: Example code (): This may or may not be related to the compiler seemingly failing to assert that , an error that can be triggered by using the alternate signature for at line 40 of the example. I tested this with the linked playground on the latest stable (1.32.0), as well as a recent nightly: Compiling with doesn't seem to yield a very useful stack but here it is:
Another example by that causes only the second "call dest mismatch" ICE:
P-medium. Removing nomination label. (But maybe we should have a WG-impl-trait to provide a structured effort for working through the bugs with impl trait?)
This has been fixed in 1.38.0 as, while I can reproduce the ICE in 1.37.0, I am not observing it in neither of: stable (1.38.0), beta nor nightly. modify labels: E-needstest

The following code works on beta: But when used in a trait like so: rustc reports the following error:
Possibly related to rustc expecting possibly a type in this scenario? As you can declare trait methods with no parameter name
Possibly related to rustc expecting possibly a type in this scenario? Exactly. When becomes an error, we'll be able to accept arbitrary patterns in parameters of trait methods, but for now only very limited subset is allowed.
The example in the issue now compiles. If we don't have existing tests for this, we ought to add one.
Change:
/// /// [book]: ../../book/borrow-and-asref.html /// <ins> /// **Note: this trait must not fail**. If the conversion can fail, use a dedicated method which /// return an `Option<T>` or a `Result<T, E>`. /// </ins> /// # Examples /// /// Both `String` and `&str` implement `AsRef<str>`:

Discussion:
Part of Here's what needs to be done to close out this issue: is great, but has a lot of abbreviations, so the wording could be cleaned up a bit. should compare itself to , and should show a sample implementation. needs far better docs, as it is one of the most misunderstood traits in Rust. Specifically it should talk about its relationship with . It also needs an example implementation. needs a lot of work; it should talk about its usage in , it should show an example implementation, and general improvement. is mostly fine, but "generic impls" should say "implementations" and it should be above examples.
I am happy to mentor anyone who wants to tackle this issue.
I would be keen to give this one a go I'm interested in understanding this section better.
Awesome, ! Let me know if I can help you help me in any way
Hey , Just a couple of questions: the issue description for the trait you say to have the generic implementations above the examples, It turns out all of the traits have the examples above the generic implementations. Should I move the generic implementations above the examples for all of the traits? adding sample implementation do you like to make a generic example or use a common example from the std lib? I only ask because I have become familiar with through the usage within the package in creating paths and was thinking of using this as an example. What are your thoughts? relationship with is where I am having a bit of trouble explaining this concisely. Are we wanting to have a brief summarization of the section in the book and do we need to reciprocate or align with the documentation for the trait? I only ask as I feel to explain the difference I am describing the trait a bit and do not want to introduce a second differing description. Thanks :smile:
Hey ! Yes, that'd be great! Ideally, we'd have both: one extremely simple example for people to be able to copy/paste, and one more realistic example. Feel free to submit one or both yes it's tough! The second edition of the book does not have that chapter; synchronizing these API docs is the right way to go
OK great :smile: I will hopefully have something in today to start picking apart.

:+1:
Hey , I had a look at the [RFC] mentioned in the contribution guide and couldn't find anything on the guidelines for line length. I only ask as one of the Travis builds failed due to the line exceeding 100 chars, so was wondering what I should be aiming for. Thanks again! :smile: [RFC]:
Standard library docs are wrapped to 80 characters. :)
This is now done!
Change:
<ins> struct Bar; impl std::ops::Mul for &mut Bar { type Output = Bar; fn mul(self, _rhs: Self) -> Self::Output { unimplemented!() } } fn main() { let ref_mut_bar: &mut Bar = &mut Bar; let ref_bar: &Bar = &Bar; let owned_bar: Bar = Bar; let _ = ref_mut_bar * ref_mut_bar; // FIXME: we should be able to suggest borrowing both side let _ = owned_bar * owned_bar; //~^ ERROR cannot multiply let _ = ref_bar * ref_bar; //~^ ERROR cannot multiply let _ = ref_bar * ref_mut_bar; //~^ ERROR cannot multiply let _ = ref_mut_bar * ref_bar; //~^ ERROR mismatched types } </ins>

Discussion:
Finally getting around to filing this issue at encouragement in this (rather embarrassing) . CC and I've tried to capture things in ; to summarize: It seems like this should generally be a valid suggestion, and we have to create a diagnostic for this; current error output doesn't help the user to discover the "right" solution at all. No response No response
Hi Erich, thanks for tagging me :) Took me a couple of minutes to refresh my memory :sweatsmile: but glad to see there is something positive coming from that thread :) Should the suggested help-message not read: Since we're not just adding a but rather a ?
I think your point is valid. Edited!
Whoot whoot!
Change:
error: path statement with no effect <del> --> $DIR/warn-path-statement.rs:5:5 </del> <ins> --> $DIR/warn-path-statement.rs:10:5 </ins> | LL |     x; |     ^^ | = note: requested on the command line with `-D path-statements` <del> error: aborting due to previous error </del> <ins> error: path statement drops value --> $DIR/warn-path-statement.rs:13:5 | LL |     y; |     ^^ help: use `drop` to clarify the intent: `drop(y);` error: path statement drops value --> $DIR/warn-path-statement.rs:16:5 | LL |     z; |     ^^ help: use `drop` to clarify the intent: `drop(z);` error: aborting due to 3 previous errors </ins>

Discussion:
() Removing the "no effect" line definitely has effect. The warning may instead suggest to explicitly use if that is what is needed.
Huh, I ran into this a couple weeks ago and typed up an issue, then decided at the last second to back out of it for some reason. Maybe I just figured that writing is more idiomatic anyways. This lint is old, by the way. (in Rust years, anyways)
requires adding before closure (somewhat suprisingly unlike ) Writing instead of may be more idiomatic if one wants to emphasize that running is significant.
Bumping this, as it's relevant to . (See also , ) When the path statement invokes a move, this lint is plain wrong; as the value has been moved, the old binding is no longer usable. When this move invokes drop glue, this lint is even more wrong, because the drop glue is an observable effect, and removing the statement would change the semantics of the program. "Path statement with no effect is further potentially damaging, as it may lead the user to write to silence the warning, which again changes the semantics of the program, because binding to the wildcard pattern does actually not perform a move from the place. I believe the correct behavior for this lint would be to suggest removing path statements that have no associated drop glue, but to suggest for types that do have drop glue, signaling clarity of intent.
Change:
<ins> // edition:2018 use ::core::pin::Pin; use ::core::future::Future; use ::core::marker::Send; trait Foo { fn bar<'me, 'async_trait, T: Send>(x: &'me T) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>> where 'me: 'async_trait; } impl Foo for () { fn bar<'me, 'async_trait, T: Send>(x: &'me T) -> Pin<Box<dyn Future<Output = ()> + Send + 'async_trait>> where 'me:'async_trait { Box::pin( //~ ERROR future cannot be sent between threads safely async move { let x = x; } ) } } 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 compiler helpfully points out that is required, but nonetheless and I both got confused by this error for some time before we noticed it. The suggestion was kind of buried by all the other details.
I'm not sure the ideal output, but it might be something like this:
This error can be replicated without any external crates (i.e., without ) like so:
Change:
} /// A delimiter token. <del> #[derive(Clone, PartialEq, RustcEncodable, RustcDecodable, Hash, Debug, Copy)] </del> <ins> #[derive(Clone, PartialEq, Eq, RustcEncodable, RustcDecodable, Hash, Debug, Copy)] </ins> pub enum DelimToken { /// A round parenthesis (i.e., `(` or `)`). Paren,

Discussion:
Many editors helpfully auto close delimiters when writing them down. It is not uncommon for this to cause the following to occur: It'd be a good idea for the parser or lexer to keep track of these empty blocks to provide an error closer to
can I take this on, if nobody is working on this?
go ahead!
Are you still working on this? I'm happy to take it if not.
Please allow me 2-3 days to check this issue.
Please take this forward.
Ok, I'll try to dive into.
Change:
<del> Subproject commit 4e44aa010c4c7d616182a3078cafb39da6f6c0a2 </del> <ins> Subproject commit 6a0f14bef7784e57a57a996cae3f94dbd2490e7a </ins>

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 compiler team prioritization.
has landed, so a fix should be possible now. are you on this or should I try my luck?
T-compiler triage: P-medium, removing nomination tag.
Change:
// issue #21405 <del> fn foo<F>(f: F) where F: FnMut(usize) {} </del> <ins> struct Foo; fn foo<F>(f: F) where F: FnMut(Foo) {} </ins> fn main() { foo(|s| s.is_empty());

Discussion:
E.g. (The repetition is .) However, all of these are useless: because one cannot implement them for anyway, it would be better to just filter them out, e.g. reject external traits when the self type itself is external. cc
Good point, although it's not always as simple as that -- with multidispatch it is plausible you COULD implement the trait for if another type parameter were local, though not with the current orphan rules. Nonetheless, it might be good to just screen them out anyway, as it is unlikely to be what you plan to do.
Change:
<ins> struct Foo; impl &mut Foo { //~^ ERROR E0118 fn bar(self) {} } fn main() {} </ins>

Discussion:
] To : This should probably use the covered/local terminology from instead of "base type" to avoid the problematic overlap with subtyping/inheritance terminology.
] ] ] (Not really [C-bug], but it was the closest of the template options.)
Just fyi, you can do modify labels to -C-bug +A-diagnostics +C-enhancement +D-newcomer-roadblock which will let you apply most labels yourself. .
Error: Label D-newcomer-roadblock can only be set by Rust team members Please let know if you're having trouble with this bot.
... Oh, unless that happens.
A second attempt :stuckouttongue: modify labels to -C-bug +A-diagnostics +C-enhancement
In the reference, we use the term "nominal type". The error code explanation should also mention unions and trait objects ( is valid). If the person use or , it should also hint at removing the reference and putting them on in the associated items. Not sure if I should open a new issue for that one or not though.
Change:
python3 ../x.py build --stage 0 src/tools/build-manifest &&  python3 ../x.py test --stage 0 src/tools/compiletest &&  python3 ../x.py test --stage 2 src/tools/tidy &&  <ins> python3 ../x.py test --stage 0 core alloc std test proc_macro &&  </ins> python3 ../x.py doc --stage 0 library/test &&  /scripts/validate-toolstate.sh &&  /scripts/validate-error-codes.sh && 

Discussion:
These tests were recently broken by It shouldn't be possible for these to be broken on master - nearly everyone who contributes to the standard library uses , and this makes it very hard to verify changes. We should get these running in mingw-check or some other builder. label +P-high +A-testsuite +T-libs Originally posted by in <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
cc Any idea re this? :)
here's where the code for mingw check lives: that job is also run on a full merge (bors r+) so it should be enough to only modify that.
Awesome, thanks!
Should be resolved by
Change:
// compile-flags: -Ztrait-solver=next <del> // check-pass </del> <ins> // known-bug: rust-lang/trait-system-refactor-initiative#38 </ins> fn test(s: &[u8]) { match &s[0..3] {

Discussion:
This code previously compiled fine, but as of ~2 weeks ago it began to fail on nightly and has continued to do so since. p.s. Is the output of suppose to be one day behind compared to the toolchain name? In any case, was the last working version, and onward trigger the error. modify labels: +regression-from-stable-to-nightly -regression-untriaged
cc
I can put up a fix for this. I suspected this might cause an issue but couldn't think how.
Change:
fn insert(&mut self, span: Span, hir_id: HirId, node: Node<'hir>) { debug_assert_eq!(self.owner, hir_id.owner); debug_assert_ne!(hir_id.local_id.as_u32(), 0); <ins> debug_assert_ne!(hir_id.local_id, self.parent_node); </ins> // Make sure that the DepNode of some node coincides with the HirId // owner of that node.

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: with rustc this runs in a couple ms: with rustc this seems to hang somewhere in ( I killed the process after waiting for 5 minutes :upsidedownface: )
reduced: RIP
I think this is caused by cc
Clearly a well tested feature :stuckouttongue: I'll take a look.
The old code looked like this: The new code looks like this: because is no longer optional. The infinite recursion happens because the call returns a that is the same as the . When I printed that ID out it looks like this: An easy fix is to check if is the same as and return if so. But I don't know if that's just papering over a deeper problem. Is it an underlying bug that can return the same node it is given?