jiebi/CodeConvo huggingface dataset:
Change:
syntax_exts, krate); if cfg!(windows) { <del> env::set_var("PATH", &_old_path); </del> <ins> env::set_var("PATH", &old_path); </ins> } *sess.available_macros.borrow_mut() = macro_names; ret

Discussion:
Mentioned in , there are two places where rustc sets and resets . Doing this means that running multiple compilations in parallel will stomp on each others' environment variables. This can happen, e.g. in rustdoc which runs tests by driving rustc directly. The proper way to set the environment for subprocesses is through the process Command type. cc
Yes, we could do that for subprocesses, but what about syntax extension dylibs? I guess this depends on why we are munging PATH/DYLDLIBRARYPATH/LDLIBRARYPATH: Is this because we want the OS to find the extension dylib itself? If so, we could just search along the augmented path ourselves, then load by absolute path. Or, is this because we need the OS to be able to find other dylibs that the extension dylib depends on? In this case, I don't see another way but to munge the PATH envvar. I don't know about Linux, but Windows does not seem to have a concept of a per-thread dll search path... looks like you wrote the relevant bit of code in Do you remember which of the two it was?
For the case 2, I suppose we could add with an internal mutex, that would temporarily alter PATH before delegating to . Of course, this would still race with direct calls to , but better than nothing. In fact, because essentially allows to mutate global variables, perhaps it should be marked as unsafe?
I thought it was case 1. Interesting idea, marking as unsafe... though note that the rules about when code needs to be annotated with is really meant to ensure data race freedom in safe code, not arbitrary race freedom
Triage: In , mentions this block of code: It looks like this code still doesn't prevent adding to the path over and over again.
I believe we've been seeing this a lot recently as , which is spurious test failures from something being too big, and it's probably environment variables ( coming back to haunt us)
Change:
/// # Examples /// /// ``` <del> /// #![feature(cmp_min_max_by)] /// </del> /// use std::cmp; /// /// assert_eq!(cmp::min_by_key(-2, 1, |x: &i32| x.abs()), 1);

Discussion:
Tracking issue for the feature, which adds the / / / functions to . PR:
Is there anything blocking this from stabilizing?
Doesn't look like it! If somebody would like to open a stabilization PR then we can start a FCP
Stabilization PR up at
Change:
sp: Span) { // Merges the module with the existing type def or creates a new one. let modifiers = if is_public { PUBLIC } else { DefModifiers::empty() } | IMPORTABLE; <del> let module_ = Rc::new(Module::new(parent_link, def_id, kind, external, </del> <ins> let module_ = Rc::new(Module::new(parent_link, def_id, kind, external, </ins> is_public)); let type_def = self.type_def.borrow().clone(); match type_def {

Discussion:
This code: generates this error: I couldn't find any existing issue on this, but this is expected to work, right?
cc
Was this in an RFC?
DST was pre-RFC (the design anyway), so no, it was not.
It as a good question whether this is supposed to work or not. Since traits are types now, just unsized, I would say "yes". But since an impl for a trait is no different to just providing default methods, perhaps we want to avoid that overlap. Shouldn't be hard to fix if we all agree on "yes", but cc to check he agrees.
As I understand it, an for a trait would be quite different than providing default methods: Even when a trait object is formed, there's no dynamic dispatch (vtable entries) for these methods. The methods cannot be overridden in an . The methods may also exist on the trait, in which case (according to our dispatch rules) the inherent versions would take precedence. I think the closer correspondence is to creating an extension trait with a blanket -- and given that inherent s are in some sense supposed to be equivalent to "anonymous", always-in-scope extension traits, I think that makes sense. My guess is that this was an intended, but implicit part of the DST proposal, but can speak more directly to that.
These subtle differences make me want it less. But the blanket impl-like use case seems legitimate. I agree with the intended but implicit assessment - I vaguely remember this coming up as a use case at some point
I've always assumed this would work but I'm curious was there a specific point in the libraries that required it?
IIRC this came out of playing around with the method definitions, which are currently all provided by extension traits. Not a huge deal if we can't do this for 1.0.
I started looking at this, but the hard bits seem to be some adjustment to method selection, so I'll wait on landing before doing this
I think there is some serious utility in providing this, especially for things like Any. I will try to dig up some other use-cases. Note that since is currently marked adding this later would mean deprecations etc.
Change:
/// /// assert_eq!(string, other_string); /// ``` <ins> /// # Generic impls /// /// - `From<T> for U` implies `Into<U> for T` /// - `from()` is reflexive, which means that `From<T> for T` is implemented /// </ins> #[stable(feature = "rust1", since = "1.0.0")] pub trait From<T>: Sized { /// Performs the conversion.

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:
impl_dep_tracking_hash_via_hash!(Lto); impl_dep_tracking_hash_via_hash!(DebugInfoLevel); impl_dep_tracking_hash_via_hash!(UnstableFeatures); <del> impl_dep_tracking_hash_via_hash!(Externs); </del> impl_dep_tracking_hash_via_hash!(OutputTypes); impl_dep_tracking_hash_via_hash!(cstore::NativeLibraryKind); impl_dep_tracking_hash_via_hash!(Sanitizer);

Discussion:
I was trying to determine if sccache could cache crates built as dependencies of different root crates. When I looked into it I found that the rlibs were not bit-identical despite being built from the same source. Most of the differences were in the debug info because the current directory winds up encoded there. I tried using which removed most of the differences but not all. A small difference in the metadata remains, which from looking at the diff of the serialized metadata said was the . do you know why this would be? I built this twice in different directories using the script. The diff of the rlib from each build (I generated that using .) Presumably this would block and also
Lots of stuff goes into the SVH. It might well be that something directory related accidentally goes into it. The SVH is computed here:
cc This is similar to the GCC build-path issue where other programs (and in the past, GCC's DWATproducer) likes to embed CFLAGS into the output. Suggested options: out -Zremap-path-prefix away from that SVH calculation - but other programs that also embed RUSTFLAGS or similar, would also need similar logic the envvar or something similar cargo support a constant flag (whose value does not depend on build-path) that figures out the right -Zremap-path-prefix for rustc so they don't need to appear in RUSTFLAGS. you'd also need to implement (1) but at least the caveat (about other programs) doesn't apply.
addresses (1), which is kind of orthogonal to (2) and (3) because the SVH will always be part of the output binary and it must change if the result of the mapping changes.
With the latest Rust nightly: which includes the fix from , the outputs from are still not the same:
I think we may still be hashing arguments?
Yes, it seems we do: Good catch! Not sure if we have to hash those at this point. The tracking system should catch resulting changes later on, if we don't have any holes in the tracking. This needs some review.
Edit: never mind - seems fixed now that I've rebased to master. I found that (after implementing it) still affects the SVH, even if the mapping does nothing: will generate different metadata hashes if I change the mapping, even though it doesn't affect anything and nothing else changes.
Change:
fn run(self, builder: &Builder) -> PathBuf { let target_compiler = builder.compiler(builder.top_stage, self.host); <ins> if target_compiler.stage == 0 { if !target_compiler.is_snapshot(builder) { panic!("rustdoc in stage 0 must be snapshot rustdoc"); } return builder.initial_rustc.with_file_name(exe("rustdoc", &target_compiler.host)); } </ins> let target = target_compiler.host; <del> let build_compiler = if target_compiler.stage == 0 { builder.compiler(0, builder.config.build) } else if target_compiler.stage >= 2 { // Past stage 2, we consider the compiler to be ABI-compatible and hence capable of // building rustdoc itself. builder.compiler(target_compiler.stage, builder.config.build) } else { // Similar to `compile::Assemble`, build with the previous stage's compiler. Otherwise // we'd have stageN/bin/rustc and stageN/bin/rustdoc be effectively different stage // compilers, which isn't what we want. builder.compiler(target_compiler.stage - 1, builder.config.build) }; builder.ensure(compile::Rustc { compiler: build_compiler, target }); builder.ensure(compile::Rustc { compiler: build_compiler, target: builder.config.build, }); </del> <ins> // Similar to `compile::Assemble`, build with the previous stage's compiler. Otherwise // we'd have stageN/bin/rustc and stageN/bin/rustdoc be effectively different stage // compilers, which isn't what we want. Rustdoc should be linked in the same way as the // rustc compiler it's paired with, so it must be built with the previous stage compiler. let build_compiler = builder.compiler(target_compiler.stage - 1, builder.config.build); // The presence of `target_compiler` ensures that the necessary libraries (codegen backends, // compiler libraries, ...) are built. Rustdoc does not require the presence of any // libraries within sysroot_libdir (i.e., rustlib), though doctests may want it (since // they'll be linked to those libraries). As such, don't explicitly `ensure` any additional // libraries here. The intuition here is that If we've built a compiler, we should be able // to build rustdoc. </ins> let mut cargo = prepare_tool_cargo( builder,

Discussion:
To reproduce, make sure you have an entirely clean checkout -- I did . Then run This will go on for a while and ultimately fail with Notably, it doesn't seem to build LLVM at all -- which may be why it can't find a codegen-backend...
Turns out that works fine. However, stage 0 tests with doctests still seem pretty much broken. Can these even reasonably work without having a "bootstrap rustdoc"?
Cc
Note that it fails in stage 1 as well -- both of these fail:
Change:
<ins> error: lifetime may not live long enough --> $DIR/supertrait-lifetime-bound.rs:10:5 | LL | fn test2<'a>() { |          -- lifetime `'a` defined here ... LL |     test1::<dyn Bar<&'a u32>, _>(); |     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ requires that `'a` must outlive `'static` error: aborting due to previous error </ins>

Discussion:
Found in () Errors: modify labels: T-compiler, C-bug, A-traits, A-dst, A-associated-items, A-typesystem and please add “I-unsound ”
cc - this looks like it might be related to some of your work.
Assigning as discussed as part of the and removing .
Without the keyword, the function type-checks since Rust 1.0.0. And a function like e.g. leads to reading a bunch of memory and segfaulting on every Rust version, as far as I can tell (at least in debug builds).
To me, this is the same root cause as : we unconditionally say that any type is well-formed and implements without checking the actual where clauses declared on the trait, so you can deduce contradictory things with the help of implied bounds (to be fair, already introduced some checks). Except that I was wrong in my saying that an easy fix for our current limited form of implied bounds would be to just check transitive lifetime requirements. Obviously, example shows that implied bounds for super traits play a role as well.
Change:
<ins> error[E0412]: cannot find type `Oops` in this scope --> $DIR/issue-104510-ice.rs:4:21 | LL | struct W<T: ?Sized>(Oops); |                     ^^^^ not found in this scope error: aborting due to previous error For more information about this error, try `rustc --explain E0412`. </ins>

Discussion:
Found by mutating with a <details<summary<strongFull output including backtrace</strong</summary<p</p</detailsnightly-2022-05-28: changed from no ICE to ICE "index out of bounds" Most likely for the same reason as nightly-2022-07-13: changed from ICE "index out of bounds" to ICE "assertion failed: self.istaintedbyerrors()" From something in , most likely label +A-inline-assembly <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOT_END --
That assertion is probably unnecessarily strict, since doesn't check that errors are emitted from other items anyways. Instead, it can probably be turned into a delayed bug or just removed altogether, since already delays a bug.
claim
Change:
<ins> fn main() { f<'a,> //~^ ERROR expected } </ins>

Discussion:
Reproducible at . <details<summaryBacktrace</summary<p</p</details<!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Seems to be introduced in :
Thanks for the report! A compiler panic is probably best reported in rust-lang/rust, even though it's being surfaced by a dev tool. I'll check with infra to see if it makes sense to move the issue We actually haven't made any changes to rustfmt in that window and the were highly minimal and certainly don't strike me as anything that would be the root cause. As such I suspect this is due to changes made elsewhere within the compiler mods, and would at least like for those folks to be aware (even if we need to make changes on the rustfmt side to address/work around) Would you be up for trying to boil it down to a more simple repro case?
Sure! Here is a MRE:
I have bisected to . cc I noticed that rustfmt is exiting with 0 even though it panicked. Is that normal?
I'll look into it today or tomorrow! claim
Outside a macro, no, (as was the case in the original full repro), but yes within the context of a macro as in the minimal rerpo. We have our calls to rustcparse internals wrapped in so the panic isn't really surfacing here, but rustfmt is still displaying the underlying error text prior to emitting formatting. This is done partly due to the fact that there are scenarios where those internals panic that we want to wrap to an error type, and partly due to there being some scenarios we want to ignore for the purposes of formatting due to how we attempt to deal with macros in the pre-expansion world where rustfmt lives. The latter being a result of limited macro support and leaving macros it can't handle alone, while carrying on formatting the rest of the file/crate/workspace
It looks like I'm still getting this error with (Coming from that was closed due to this one) Playground seems to produce it also:
I'll take another look then.
Yeah, this continues to ICE even in rustc. Fixed in another PR.
Change:
let mut generator = static || { yield; }; <del> assert_unpin(generator); //~ ERROR std::marker::Unpin` is not satisfied </del> <ins> assert_unpin(generator); //~ ERROR E0277 </ins> }

Discussion:
gives The in particular is confusing. This can be a pretty intimidating error message for someone new to async/await, when all they forgot was . I'm not sure if we can fix this without stabilizing so we can sprinkle some magic compiler dust on its error messages. Maybe there's something we can do, though. Maybe some intelligent use of type aliases in our error messages? cc
This can be handled without needing to stabilize the struct. It should act the same way that the primitive type cast suggestions do.
Some observations: There is no struct, it's a type-alias We could suggest invoking but that is a method defined only in the futures crate, which feels a bit awkward to me; I'd rather it were part of libstd We can* suggest as well ()
marking as OnDeck, since BoxFuture gets used quite often
I have a PR that suggests the right code for this: <img width="1269" alt="Screen Shot 2020-02-11 at 5 09 37 PM" src="https://user-"But if first you try : <img width="1271" alt="Screen Shot 2020-02-11 at 5 10 12 PM" src="https://user-"or : <img width="1303" alt="Screen Shot 2020-02-11 at 5 11 11 PM" src="https://user-"we will send you in a wild goose chase: <img width="946" alt="Screen Shot 2020-02-11 at 5 10 53 PM" src="https://user-"
Filed for the uncovered cases.
Change:
<del> //! Codegen the completed AST to the LLVM IR. //! //! Some functions here, such as `codegen_block` and `codegen_expr`, return a value -- //! the result of the codegen to LLVM -- while others, such as `codegen_fn` //! and `mono_item`, are called only for the side effect of adding a //! particular definition to the LLVM IR output we're producing. //! //! Hopefully useful general knowledge about codegen: //! //! * There's no way to find out the `Ty` type of a `Value`. Doing so //!   would be "trying to get the eggs out of an omelette" (credit: //!   pcwalton). You can, instead, find out its `llvm::Type` by calling `val_ty`, //!   but one `llvm::Type` corresponds to many `Ty`s; for instance, `tup(int, int, //!   int)` and `rec(x=int, y=int, z=int)` will have the same `llvm::Type`. </del> use crate::back::write::{ compute_per_cgu_lto_type, start_async_codegen, submit_codegened_module_to_llvm, submit_post_lto_module_to_llvm, submit_pre_lto_module_to_llvm, ComputedLtoType, OngoingCodegen,

Discussion:
The reference functions named and , but those functions anywhere in rustc. It seems the docs for this module have , so perhaps that is why?
modify labels to T-doc C-enhancement
It looks like has the .
modify labels: A-codegen
I finally have enough knowledge to fix these!
Change:
use crate::collections::BTreeMap; use crate::env; use crate::ffi::{OsStr, OsString}; <ins> use crate::fmt; </ins> use crate::io; use crate::sys::pipe::read2; use crate::sys::process::{EnvKey, ExitStatus, Process, StdioPipes}; // Stores a set of changes to an environment <del> #[derive(Clone, Debug)] </del> <ins> #[derive(Clone)] </ins> pub struct CommandEnv { clear: bool, saw_path: bool,

Discussion:
currently only outputs the program and it's arguments. It should also output the environment variables and the current path, as set by , and . This would help with figuring out what's going on :-)
We also currently have no way to extract most of this information without utilizing Debug, so out of tree implementations can't be implemented.
Would/should this be the specific additions to the environment set by , or the actual environment? The most straightforward implementation of this (debug-printing the individual fields of the internal struct) seems to do the latter. That is, this patch (in )— results in program behavior like this (scroll right to see the very bulky output; should be verbose, but how verbose is too verbose??):
I'd be fine with the verbose output. The debug output is only meant for debug purposes and generating the full environment saves us from oh-that's-why-it's-not-working-this-stupid-thing moments
Seems reasonable. I would be ready to consider a PR implementing this.
Triage: no changes here. I've actually wanted this too, but don't have the bandwidth to work on it, personally.
Change:
<ins> // Copyright 2018 The Rust Project Developers. See the COPYRIGHT // file at the top-level directory of this distribution and at // http://rust-lang.org/COPYRIGHT. // // Licensed under the Apache License, Version 2.0 <LICENSE-APACHE or // http://www.apache.org/licenses/LICENSE-2.0> or the MIT license // <LICENSE-MIT or http://opensource.org/licenses/MIT>, at your // option. This file may not be copied, modified, or distributed // except according to those terms. // compile-pass #[derive(Copy, Clone, PartialEq, Eq)] #[repr(packed)] pub struct Num(u64); impl Num { pub const ZERO: Self = Num(0); } pub fn decrement(a: Num) -> Num { match a { Num::ZERO => Num::ZERO, a => Num(a.0 - 1) } } fn main() { } </ins>

Discussion:
I recently updated my nightly toolchain for rust, and compiled a project I was working on. Previously I was on the version, and updated to the version. I encountered a compiler error when dealing with statements and Associated Constants, centered around alignment issues of the associated constant. After some testing, I managed to create a simple example with the code below: : : I've also tested and encountered this error on the following versions: nightly-2018-04-27-x8664-pc-windows-msvc nightly-2018-04-28-x8664-pc-windows-msvc nightly-2018-04-29-x8664-pc-windows-msvc nightly-2018-04-30-x8664-pc-windows-msvc
Sounds like some alignment check is getting the alignment from the wrong side of an assignment. I hope it wasn't introduced in a beta backported bugfix, we need to check that.
Ok, It's just in nightly, not in beta! I'll try to bisect