jiebi/CodeConvo huggingface dataset:
Change:
<ins> // Copyright 2013 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. // xfail-fast // aux-build:issue-7178.rs extern mod cross_crate_self = "issue-7178"; fn main() { let _ = cross_crate_self::Foo::new(&1i); } </ins>

Discussion:
Having a generic seems to be necessary to exhibit the bug. (Caused .)
Reproduced with . Nominating.
cc me
declining; just-a-bug
cc me; possibly addressed by patch to
This has been fixed, adding a test for it soon.

Nominating well defined.
This seems to be fixed.
Not quite: If you put on the inner module, it works. I think this is actually working as intended: the 'pub' on the item being re-exported is itself the indication of whether it can be seen from outside. Curiously, you can't use it locally (with no anywhere in the file) either. This feels not entirely well defined? Or else I'm not well informed enough to address it. Leaving open until we have Patrick around for subsequent triage.
My two cents: makes sense that a 'd item must be , since that means you don't have to search for a pub use. seems like ought to work though.
accepted for well-defined milestone
This is working now. I think my extraction of privacy from resolve has fixed this. Removing all tags and flagging as needstest.
Change:
<ins> // Copyright 2013 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. // xfail-fast // aux-build:issue-7178.rs extern mod cross_crate_self = "issue-7178"; fn main() { let _ = cross_crate_self::Foo::new(&1i); } </ins>

Discussion:
With the following test code: You get an ICE:
Looks quite similar to , which is probably .
After updating for removal of and feature-gating of macros, I don't get ICE any more.
Almost certainly fixed by

This code: Causes the ICE cc
Also a similar, but different error:
I've also confirmed that if everything is defined in the same crate, it all compiles just fine.
This may be related to , although it's a different error message so I'm not sure of it.
This is not related to
I just ran into this myself. One interesting thing I found is that the error happens due to the empty variant. This compiles fine for me:
Appears to be fixed now, flagging as needstest.

To replicate: (Original report follows:) I had code like this: This causes rustc to spin forever. Here's the interesting part of the stack trace:
In my attempt to replicate the bug (on a Mac OS machine), this appears to ICE now rather than hang.
(The fact that it ICE's now rather than diverges is probably thanks to )
Reproduced with
This was fixed at some point, the error message is now: which is exactly what one would expect! Flagging as needstest.
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 coercing bare fn's that return a zero sized type to // a closure doesn't cause an LLVM ERROR struct Foo; fn uint_to_foo(_: uint) -> Foo { Foo } #[allow(unused_must_use)] fn main() { range(0u, 10).map(uint_to_foo); } </ins>

Discussion:
Out:
It seems to occur even without UFCS:
The problem seems to be with zero-sized types. Since this works fine:
Ok, yea the problem is when we coerce a bare fn that returns a zero sized type to a closure. I'll put up a PR once I've tested this fix a bit.
Change:
<del> error[E0282]: type annotations needed for `Expr<'_, VAR>` --> $DIR/issue-23046.rs:17:15 </del> <ins> error[E0282]: type annotations needed for the closure `fn(Expr<'_, _>) -> Expr<'_, _>` --> $DIR/issue-23046.rs:18:9 </ins> | <del> LL |     let ex = |x| { |               ^ consider giving this closure parameter the explicit type `Expr<'_, VAR>`, where the type parameter `VAR` is specified </del> <ins> LL |         let_(add(x,x), |y| { |         ^^^^ cannot infer type for type parameter `VAR` declared on the function `let_` | help: give this closure an explicit return type without `_` placeholders | LL |             let_(add(x, x), |x|-> Expr<'_, _> { x })})}; |                                ^^^^^^^^^^^^^^^^   ^ </ins> error: aborting due to previous error

Discussion:
This compiles just fine: But this gives a compiler error: It seems really weird that the second statement is affected like this? Empty project (created with ), unmodified (so no extra dependencies): <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --This issue has been assigned to via . <!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
It is actually that the first statement has type error, but somehow the error is reported to the second statement. The first statement alone reports the error correctly and by fixing the error, the following compiles fine
This happens on Nightly and on Stable.
Labeling as this was a regression introduced by 1.41.0.
Assigning .
Problem seems to be that we always assume the last closure was the source of the inference failure
Just sticking a return after is enough to get the correct diagnostic in this specific instance. However, we clearly need to be smarter than that, as in a sequence of closures, any of them could be the source of an inference error (current implementation always assumes last, just adding a return always assumes first).
Definitely not the case - looking into some alternative fixes. claim
Ok this is even more subtle than I first thought. There's just far too much ambiguity here for this diagnostic code to produce a sensible suggestion. Any time a sub-expression/local pattern/argument pattern/closure's type contains the inference target it immediately becomes a candidate for suggesting on. In this case though, the inference target is , so any code that has anything to do with strings will trip the diagnostic...
Compiling the above results in this - clearly the has nothing to do with the error...
I have a similar message to: But what I don't understand is: why does it complain it can't infer the type if it clearly knows the type?
Change:
<ins> error[E0061]: this function takes 1 argument but 0 arguments were supplied --> $DIR/mismatch-args-crash-issue-130400.rs:4:9 | LL |         Self::foo() |         ^^^^^^^^^-- argument #1 is missing | note: method defined here --> $DIR/mismatch-args-crash-issue-130400.rs:2:8 | LL |     fn foo(&mut self) -> _ { |        ^^^ --------- help: provide the argument | LL |         Self::foo(/* value */) |                  ~~~~~~~~~~~~~ error[E0121]: the placeholder `_` is not allowed within types on item signatures for return types --> $DIR/mismatch-args-crash-issue-130400.rs:2:26 | LL |     fn foo(&mut self) -> _ { |                          ^ not allowed in type signatures error: aborting due to 2 previous errors Some errors have detailed explanations: E0061, E0121. For more information about an error, try `rustc --explain E0061`. </ins>

Discussion:
<!-- ICE: Rustc '' 'thread 'rustc' panicked at 'assertion failed'', 'thread 'rustc' panicked at 'assertion failed'' File: /home/gh- --auto-reduced (treereduce-rust): original: Version information ` <!-- query stack: [typeck] type-checking [fnsig] computing function signature of --<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details
Possibly related to , possibly somewhat related to , cc very astute assertions!
claim
Change:
use std::iter; use std::path::{Path, PathBuf}; use std::str::{self, FromStr}; <ins> use std::sync::LazyLock; </ins> pub mod sigpipe;

Discussion:
rustc --edition: rustc --edition=help: --editionhelprustc --help The default is not mentioned anywhere. I assume it is 2015? <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
The default is indeed 2015. It should probably not only mention the default (2015) but also the latest stable edition (2021).
Mentoring instructions: modify to include and somewhere.
claim
What is the best way to insert the values for and into the string? only takes 's and I don't see an easy way to create one while inlining those variables. Neither nor works - former only accepts literals rather than the static variable, and the latter would create a &str, but then drop a temporary variable. I don't believe it would be a good idea to simply write the value of these variables into the string, so I'm wondering what other options I have. However, if that's the way forward, I can do so.
Where does that requirement come from? Seems fine to loosen it.
ah I see, the string ends up stored in RustcOptGroup. Honestly, given that this is only used once and the string is tiny, using seems fine.
Change:
<ins> // check-pass // Check that the anonymous lifetimes used here aren't considered to shadow one // another. Note that `async fn` is different to `fn` here because the lifetimes // are numbered by HIR lowering, rather than lifetime resolution. // edition:2018 struct A<'a, 'b>(&'a &'b i32); struct B<'a>(&'a i32); impl A<'_, '_> { async fn assoc(x: &u32, y: B<'_>) { async fn nested(x: &u32, y: A<'_, '_>) {} } async fn assoc2(x: &u32, y: A<'_, '_>) { impl A<'_, '_> { async fn nested_assoc(x: &u32, y: B<'_>) {} } } } fn main() {} </ins>

Discussion:
Hello, I ran into a problem using lifetime with async struct methods, here is the example: struct Foo<'a{ swag: &'a i32 } impl Foo<'{ async fn bar(&self) -i32 { 1337 } } The error is: '_ Everything is fine if I use explicit lifetime like . Version: 1.39 Nighly (2019-09-19 on playground)
This is happening because the desugaring of uses the lifetime. This is sort of unfortunate, but seems backwards compatible to fix, so I don't think we should block on this.
We decided to focus on this one in the WG meeting -- you still interested in working on it?
Yes, I'm still interested in working on this. I don't think that this should be too hard to fix though if someone else wants it.
Change:
/// /// See BTreeMap's documentation for a detailed discussion of this collection's performance /// benefits and drawbacks. <ins> /// /// It is a logic error for an item to be modified in such a way that the item's ordering relative /// to any other item, as determined by the `Ord` trait, changes while it is in the set. This is /// normally only possible through `Cell`, `RefCell`, global state, I/O, or unsafe code. </ins> #[derive(Clone, Hash, PartialEq, Eq, Ord, PartialOrd)] #[stable(feature = "rust1", since = "1.0.0")] pub struct BTreeSet<T>{

Discussion:
Collections that perform lookups based on a given property (e.g. a hash or an ordering) can be put into an inconsistent state when the property changes while its corresponding item is in the collection. This is normally not a problem, because such collections (at least those in ) do not provide mutable access to the type from which the property is derived (keys in the case of maps, items in the case of sets), but types with interior mutability can induce this behavior in safe code: Output: This is obvious from the definition of interior mutability, but it's definitely a footgun. If the use of such keys cannot be prevented with the type system, the collections should at least document that the property must remain constant for the duration of the item's presence in the collection. For example, Java's contains the following note:
This is a dupe of , which was for reasons in the thread itself. I believe the gist of the conversion was that yes, this can happen. Our implementations should ensure that this does not cause memory unsafety, but otherwise these sorts of "odd assertions" are ok to happen as this should be quite a rare occurrence anyway.
I still think the collection documentation needs to identify this problem. On Friday, March 13, 2015, Alex Crichton wrote:
Hm good point! I've an appropriate tag.
I'm working on a patch to document this.
Change:
/// `.foorc`: /// /// ```no_run <del> /// #![feature(iter_once_with)] /// </del> /// use std::iter; /// use std::fs; /// use std::path::PathBuf;

Discussion:
This is the tracking issue for . Currently in nightly, PR = .
Is this function now ready for stabilization?
I don’t see why not. Tracked here: 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] [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.
I noticed that this iterator has been stabilized a impl which I assume wasn't intentional so I've submitted to remove it.
Change:
mod tests { use sync::mpsc::channel; use sync::{Condvar, Mutex, Arc}; <ins> use sync::atomic::{AtomicBool, Ordering}; </ins> use thread; use time::Duration; <del> use u32; </del> <ins> use u64; </ins> #[test] fn smoke() {

Discussion:
I have encountered what I think is unexpected behavior from on OSX: when called with "large" values the call will return immediately, instead of waiting for an call. What constitutes "large" is variable, and appears to correspond to the current value in the system monotonic clock source. The following code reproduces the issue: If you run the code above with the "small" value uncommented the internal loop only runs once, waiting for the 1-second sleep to expire before is called. But if you run with the "large" value uncommented, the internal loop runs a very large number of times as each call to returns almost immediately. As noted above, the actual value of "large" decreases over time, I believe based on . I unfortunately couldn't come up with a way to prove this is the case. I've seen this behavior on OSX Yosemite and Sierra. Edit: this happens on 1.11, 1.12, beta, and nightly.
This is likely related to the implementation using unchecked arithmetic and something overflowing. I'll tweak it to much Linux and test out to make sure it works.
Hm no that's correctly handling overflow... Hmm...
Fixed by
Change:
$$(HLIB$(2)_H_$(4))/libcore.rlib  $$(HLIB$(2)_H_$(4))/libstd.rlib  $$(HLIB$(2)_H_$(4))/$$(CFG_RUNTIME_$(4))  <del> | $$(HBIN$(2)_H_$(4))/ </del> <ins> | $$(HLIB$(2)_H_$(4))/ </ins> @$$(call E, cp: $$@) $$(Q)cp $$< $$@ $$(HLIB$(2)_H_$(4))/$(CFG_RUSTLLVM_$(4)):  $$(TLIB$(1)_T_$(4)_H_$(3))/$(CFG_RUSTLLVM_$(4))  <del> | $$(HBIN$(2)_H_$(4))/ </del> <ins> | $$(HLIB$(2)_H_$(4))/ </ins> @$$(call E, cp: $$@) $$(Q)cp $$< $$@ $$(HBIN$(2)_H_$(4))/: mkdir -p $$@ <ins> $$(HLIB$(2)_H_$(4))/: mkdir -p $$@ </ins> endef $(foreach t,$(CFG_HOST_TRIPLES),					

Discussion:
There comes a time in the life of every Rust developer when they have to blow away various parts of the directory to avoid messages about "multiple matching crates". Then when they do the next build they get things like: . It would be better if the Makefile would just create all the needed parent directories automatically.
+1
I'm pretty sure I know how to do this. (I think the right tools for the job are some in and )
I haven't actually waited for a whole build to go through yet, and I have to leave for the evening. But I'd welcome it if you would be willing to pull this (SHA: ) into your repo and give it a spin. If you don't get around to it, no sweat; it can obviously wait until Monday.
argh ignore comment above; the commit isn't anywhere near fully baked yet; somethings off with my make syntax.
Okay. It would be nice to do this in the interim, but eventually when rustpkg is the build system it will do this (much more easily than with Makefile hacking), so no sweat if you don't get it done :-)
Change:
/// Invalid metadata in a wide pointer (using `str` to avoid allocations). InvalidMeta(&'static str), /// Invalid drop function in vtable. <del> InvalidDropFn(FnSig<'tcx>), </del> <ins> InvalidVtableDropFn(FnSig<'tcx>), /// Invalid size in a vtable: too large. InvalidVtableSize, /// Invalid alignment in a vtable: too large, or not a power of 2. InvalidVtableAlignment(String), </ins> /// Reading a C string that does not end within its allocation. UnterminatedCString(Pointer), /// Dereferencing a dangling pointer after it got freed.

Discussion:
The following code ICEs: To fix this, this code here needs to properly catch the "invalid size/align" error and turn it into a validation failure: But for this we first need to make these errors catchable by introducing separate variants into this enum: You can use the existing variant as a model; it does the same job for invalid drop function pointers in the vtable. Cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I'll take care of this claim
Change:
warning: ignoring --out-dir flag due to -o flag <del> error: io error modifying /does-not-exist/ </del> <ins> error: io error modifying ./does-not-exist/ </ins> error: aborting due to previous error; 1 warning emitted

Discussion:
The test fails for me locally on the master branch (and was failing for a while now). I can of course ignore it, but it's annoying. also fails if run after/with . It looks like successfully creates a temp directory even if it's parent does not exist: <details<summaryoutput</summary<p</p</detailsThis causes the failure (as the test is expected to not compile) and also creates the directory, which then observes and also fails. This happens for me on the . cc iirc you had the same problems cc you changed those tests at some point, so maybe you know something
Summing up findings from discord, This test is wrong in its entirity since it gambles on permissions. The underlying subcommand creates the dir if you have enough permission to create in so it would fail. Otherwise, the directory is never created due to insufficient user permission, so the test passes. To sum it up, the test passed (for me) since I did not have enough permission to create a new directory () in : !
The test assumes that the compiler uses and so it must fail to create , but this is actually not the case: The test happens to pass in the CI and for many developers because you generally can't create a directory in . However this is not always the case (for example I happen to run tests in chroot). suggests that the proper fix for the test would be for the test to create an inaccessible directory, basically making a analog to
That still doesn't work if you're the root user, but I guess that's not what you're doing in your chroot? You could use a path like where even root can't create anything, but there's no OS-agnostic path like that.
I guess my point is that was broken on root anyway (because root has access to , same as in chroot). The explanation in the test was because of the original test it looks like, which works because it uses which requires at least the "parent must exist". So change -- now works on root, but doesn't work on chroot anymore does not work on root/chroot, but also doesn't clobber My change: unchanged now works in chroot Sooo, while fails on root, since it doesn't have global effects (clobbering as it originally did), I don't think it's a big deal.

IMO you are not supposed to run tests on root (but it's also bad for tests to have global effects)...
Yeah, that's fair -- we don't have to support root, but it should at least do no harm. While you're poking at that, maybe you can fix the filename spelling to "inaccessible"?
Fixed the spelling, thanks.
Change:
return os.path.join(self.bin_root(), '.cargo-stamp') def rustc_out_of_date(self): <del> if not os.path.exists(self.rustc_stamp()): </del> <ins> if not os.path.exists(self.rustc_stamp()) or self.clean: </ins> return True with open(self.rustc_stamp(), 'r') as f: return self.stage0_rustc_date() != f.read() def cargo_out_of_date(self): <del> if not os.path.exists(self.cargo_stamp()): </del> <ins> if not os.path.exists(self.cargo_stamp()) or self.clean: </ins> return True with open(self.cargo_stamp(), 'r') as f: return self.stage0_cargo_date() != f.read()

Discussion:
Errors like are happening on the bots, e.g.: This is under the covers, but rustbuild's command should blow away the build system directory ahead of time to be more resilient to bugs like this.
Change:
let mut need_migrations = Vec::new(); for (&var_hir_id, _) in upvars.iter() { <del> let ty = resolve_ty(self, closure_span, body, self.node_ty(var_hir_id)); </del> <ins> let ty = self.infcx.resolve_vars_if_possible(self.node_ty(var_hir_id)); </ins> if !ty.needs_drop(self.tcx, self.tcx.param_env(closure_def_id.expect_local())) { continue;

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. --Removing allows the code to compile successfully. <!-- 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 --<!-- TRIAGEBOT_END --
cc
I dont have too much context on how type folding works, but my guess is we are calling fold sooner that we should. I have this to the for RFC 2229, I'll bring it up during our sync tomorrow.
We want to use .
assign
Error: Parsing assign command in failed: ...'bot assign' ''... Please let know if you're having trouble with this bot.
claim
Thanks
Change:
/// transitively: if `T: PartialOrd<U>` and `U: PartialOrd<V>` then `U: PartialOrd<T>` and `T: /// PartialOrd<V>`. /// <ins> /// ## Derivable /// /// This trait can be used with `#[derive]`. When `derive`d, it will produce a lexicographic /// ordering based on the top-to-bottom declaration order of the struct's members. /// /// ## How can I implement `Ord`? /// </ins> /// PartialOrd only requires implementation of the `partial_cmp` method, with the others generated /// from default implementations. ///

Discussion:
I'm using s as keys in a BtreeMap. I have to look up the map ~15 million times per second (10G ethernet line rate). Ipv4Addr cmp() compiles to this on my system (linux x86-64, rustc 1.10.0-nightly ( 2016-05-21)) Which seems kinda inefficient for a thing which is basically u32. I guess part of the reason is the which converts it to an array(!) first. I copied the definition and implemented Ord like this: It's about 10 times faster on my .
Nice find! Want to send a PR for this? Looks like something that'd be more than welcome :)