jiebi/CodeConvo huggingface dataset:
Change:
is_optional_tool: true, source_type: SourceType::InTree, allow_features: concat!($($allow_features)*), <del> }) </del> <ins> })?; if (false $(|| !$add_bins_to_sysroot.is_empty())?) && $sel.compiler.stage > 0 { let bindir = $builder.sysroot($sel.compiler).join("bin"); t!(fs::create_dir_all(&bindir)); #[allow(unused_variables)] let tools_out = $builder .cargo_out($sel.compiler, Mode::ToolRustc, $sel.target); $(for add_bin in $add_bins_to_sysroot { let bin_source = tools_out.join(exe(add_bin, $sel.target)); let bin_destination = bindir.join(exe(add_bin, $sel.compiler.host)); $builder.copy(&bin_source, &bin_destination); })? let tool = bindir.join(exe($tool_name, $sel.compiler.host)); Some(tool) } else { Some(tool) } </ins> } } )+

Discussion:
Running doesn't include miri as part of the built rust toolchain, meaning that doesn't work cc <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
label +A-rustbuild
It seems like the same thing happens to rustfmt: doesn't include rustfmt as part of the built rust toolchain, meaning that doesn't work.
The same thing applies to and .
We need to call in all of these steps. I think that currently adds all libraries as well which isn't correct - someone should look into how this is done for rustdoc and do the same for the other tools. Take a look around I agree it's a bug that we don't copy these today.
claim
this seems related to
claim

This is derived from , in which we concluded that the bug should be filed against rustc, as it's an problem. In rustc: Then in a project using this toolchain via a rustup link: But note that does not make this work either, so there is probably more to it? Thanks <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
[removed comment, wrong issue, sorry]
(I think you posted that comment in the wrong place.)
Oops, yes.
Can anyone comment on what the correct fix for this might be? I notice that if I copy and from into then I'm able to run via the linked toolchain. I initially considered changing rustup to add to the PATH, but that seems incorrect as we would be adding something outside of the toolchain root to PATH. So should x.py copy or move the binaries from into ? I'm willing to (attempt to) do the work if we can agree on what the correct fix is.
I'm not really knowledgeable about . You might want to ask in on Zulip.
Yes, it should copy the binaries from stage1-tools-bin to stage1/bin.
Mentoring instructions: Add a new argument to the macro that says whether the tool should be to the sysroot, then copy it into the sysroot just after
I believe this will be fixed by , once we figure out some problems with clippy/fmt builds.
claim
Change:
// borrow_kind of the upvar to make sure it // is inferred to mutable if necessary let mut upvar_capture_map = self.fcx.inh.upvar_capture_map.borrow_mut(); <del> let ub = &mut upvar_capture_map[upvar_id]; </del> <ins> let ub = upvar_capture_map.get_mut(&upvar_id).unwrap(); </ins> self.adjust_upvar_borrow_kind(upvar_id, ub, borrow_kind); // also need to be in an FnMut closure since this is not an ImmBorrow

Discussion:
I believe we intend to eventually extend the index traits with the ability to override the syntax specifically using a trait like . This would allow hashmaps to be used like and have that insert the key, unlike today where will panic if is not already present. To pave the way, the simplest thing is to remove the operator from those collections where we would anticipate growing on demand. I believe that would be , , and possible and . Thoughts? cc
triage: P-backcompat-libs I-needs-decision (1.0 beta)
triage: P-backcompat-libs (1.0 beta)
I was just starting to prep a PR to resolve this by removing the impl, as you suggested. :)
Don't we want to keep the implementation on for example to do something like ?
Depending on the exact way that is done, it may not be possible to provide both modes of use. That is, we want to be able to write -- which we cannot today -- but it's not clear that you can do that and also support examples like the one you gave. In particular, that involves adjusting inference to determine whether or not a deref is in play. For now, removing these impls will give us the most freedom when we do incorporate .
It seems weird to have this and insert -- insert has a return value, though. This would be a super-annoying ergonomic regression in the interim. What's the expected timeline for something like IndexSet? 1.1?
Oh actually upon reflection most usages I know are Index, not IndexMut. Not as awful a regression.
It should be possible to move in, out, and take references with the operator. If that's not possible with the current design then the current design has to be changed instead of committing to yet another subpar design until 2.0.
sounds powerful and interesting, is there any RFC for it now?
It feels odd that does not support . I don't buy the argument that would be confused with - no other container supports insertion via the syntax. Now if you would add some hypothetical and support insertion into a via , then someone would just get confused that they can't use to insert into a .. (doesn't really makes sense, but what if entries are default constructible!) Not even talking about the pandora box of accidentally inserting elements into the container. Imho we should keep consistent as an accessor to get references to data already existing in the container.
Change:
<ins> struct Foo<T, const N: usize> { array: [T; N], } trait Bar<const N: usize> {} impl<T, const N: usize> Foo<T, N> { fn trigger(self) { self.unsatisfied() //~^ ERROR the trait bound `T: Bar<N>` is not satisfied } fn unsatisfied(self) where T: Bar<N>, { } } fn main() {} </ins>

Discussion:
Regression from stable 1.66 / beta 1.67 -nightly 1.68 (haven't bisected). Stable/beta correctly produce an error, nightly ICEs. I've also confirmed the behavior on the latest commit to master (, at time of writing). (nightly — ICE) (beta — error as expected) (stable — error as expected) Setting produced the same output as above. I tried to dig into this, struggled to make sense of the typechecking code. I think the following is going on: <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
cargo-bisect-rustc seems to think this is caused by of which looks like the most plausible candidate since it touched type relation code which calls without handling infer vars :thinking: cc
Ugh i'll fix it claim
WG-prioritization assigning priority (). label -I-prioritize +P-high
This is a bit weird, but I was able to come up with an alternative reduction (after hit it on - we use a pinned nightly so this is mostly a coincidence): I'm not sure why the inference variable vs generic param makes a difference like that, but I wasn't able to combine the two reductions together. Also, the ICE query stack confirms the / split between nightly versions, even in the combined example.
Change:
// option. This file may not be copied, modified, or distributed // except according to those terms. <del> // xfail-test </del> enum side { mayo, catsup, vinegar } enum order { hamburger, fries(side), shake } enum meal { to_go(order), for_here(order) }

Discussion:
This should print , but prints . The problem seems to be the pattern, since if this is replaced by aokok_` is not important.)
Confirmed. Bugs where we actually generate the wrong code are pretty bad, so fixing this is probably decently high priority. Not sure it actually fits for a milestone, though?
OK, I've figured out what is going on. The problem is that the matcher is too strict when deciding what patterns are included in some condition. Essentially the problem is that it decides that the condition that are relevant are "length 1" and "length 0" and decides that [2, .. ] is the only pattern that matches "length 1", which is obviously bogus. Fixing this seems a bit tricky, since we need to be able to properly expand out the patterns while still properly handling bindings. Note that this seems like a degenerate case, since the last pattern could just be replaced with a , but there are more complicated and interesting things where this happens too.
Oh, no, there is a pretty simple solution to this. The trick is, when checking submatches generated by a vector length check, set it up so that if none of the subpatterns match, it goes to the next vector length check. I'm explaining it poorly, but it is a really simple fix.
Simple fix has problems, though. So have a more complex fix. Which also has problems. Still investigating.
OK, have it all fixed. Just trying to document it well at this point.
Change:
|                                        ^^ recursive `async fn` | = note: a recursive `async fn` must be rewritten to return a boxed `dyn Future` <ins> = note: consider using the `async_recursion` crate: https://crates.io/crates/async_recursion </ins> error: aborting due to previous error

Discussion:
We should suggest the use of when writing :
Is there any precedent for the compiler suggesting an external crate?
Yes, for async traits the compiler suggests to use :
As pointed out, we do for . We normally wouldn't recommend one crate over another ("don't play favorites"), but for small, single use, specialized crates that fill a common language "hole" that we might be working towards "plugging", I think it is a much better experience to immediately unblock newcomers than send them to a user forum to ask how to get around the limitation. The current error gives some idea of how to fix this, but not nearly enough for an even moderately knowledgeable Rust user to fix the problem without some searching. That being said, thanks for double checking and mildly pushing back on a potentially controversial and "uncommon" request. That is important for the health of the project.
Change:
<ins> use alloc::rc::Rc; use alloc::sync::Arc; use alloc::task::{LocalWake, Wake}; use core::task::{LocalWaker, Waker}; #[test] fn test_waker_will_wake_clone() { struct NoopWaker; impl Wake for NoopWaker { fn wake(self: Arc<Self>) {} } let waker = Waker::from(Arc::new(NoopWaker)); let clone = waker.clone(); assert!(waker.will_wake(&clone)); assert!(clone.will_wake(&waker)); } #[test] fn test_local_waker_will_wake_clone() { struct NoopWaker; impl LocalWake for NoopWaker { fn wake(self: Rc<Self>) {} } let waker = LocalWaker::from(Rc::new(NoopWaker)); let clone = waker.clone(); assert!(waker.will_wake(&clone)); assert!(clone.will_wake(&waker)); } </ins>

Discussion:
I would expect this to run to completion: On stable, it does: But not on current nightly: Interestingly, it works ok without cargo: The cargo project isn't special though: OS: macOS 13.6.3
cc I guess?
The internal function uses const promotion for the vtable in two places, once at initial construction and another when cloning. Maybe that results in two differently-addressed vtables.
I gave this a shot in . But without a language feature for statics with type parameters, we are not seeing a reliable way to restore 's functionality. Let's consider reverting . Having be a handful of CPU instructions faster but way more often wrong is not useful.
Change:
.emit(); error = true; } <ins> for attr in it.attrs { if attr.check_name(sym::track_caller) { tcx.sess .struct_span_err( attr.span, "`main` function is not allowed to be `#[track_caller]`", ) .span_label( main_span, "`main` function is not allowed to be `#[track_caller]`", ) .emit(); error = true; } } </ins> if error { return; }

Discussion:
Crash occurs in both 1.46.0 beta and in current nightly. : <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
I made the false assumption that this was rustc crashing, but it's actually the binary that crashes upon running it.
Cc We probably just want to ban track caller on main (and maybe any lang item function?)
claim
Same with : results in edit: I think is a more general problem so I won't change that here
Assigning as and removing .
Change:
use super::{has_expected_num_generic_args, FnCtxt}; use crate::Expectation; use rustc_ast as ast; <del> use rustc_errors::{self, struct_span_err, Applicability, Diagnostic}; </del> <ins> use rustc_errors::{self, struct_span_err, Applicability, Diagnostic, DiagnosticBuilder}; </ins> use rustc_hir as hir; use rustc_infer::infer::type_variable::{TypeVariableOrigin, TypeVariableOriginKind}; use rustc_infer::traits::ObligationCauseCode;

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:
if let SelfSource::QPath(ty) = source && !valid_out_of_scope_traits.is_empty() && let hir::TyKind::Path(path) = ty.kind <del> && let hir::QPath::Resolved(_, path) = path && let Some(def_id) = path.res.opt_def_id() </del> <ins> && let hir::QPath::Resolved(..) = path </ins> && let Some(assoc) = self .tcx .associated_items(valid_out_of_scope_traits[0])

Discussion:
<!-- [31mICE[0m: Rustc '' 'error: internal compiler error: unexpected non-type Node::GenericParam: Type { default: None, synthetic: false }', 'error: internal compiler error: unexpected non-type Node::GenericParam: Type { default: None, synthetic: false }' File: --auto-reduced (treereduce-rust): &lt;details&lt;summary&lt;strongoriginal code&lt;/strong&lt;/summary&lt;poriginal: </p</detailsVersion information ` Command: <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongProgram output</strong</summary<p</p</details<!-- query stack: [typeof] computing type of [typeck] type-checking --
mvce:
:thinking: cc
I'm gonna assume that it is this line that needs additional logic:
Change:
self.try_run(patchelf.arg(fname)); } <del> pub(crate) fn download_component(&self, base: &str, url: &str, dest_path: &Path) { </del> <ins> pub(crate) fn download_component( &self, base: &str, url: &str, dest_path: &Path, help_on_error: &str, ) { </ins> // Use a temporary file in case we crash while downloading, to avoid a corrupt download in cache/. let tempfile = self.tempdir().join(dest_path.file_name().unwrap()); // FIXME: support `do_verify` (only really needed for nightly rustfmt) <del> self.download_with_retries(&tempfile, &format!("{}/{}", base, url)); </del> <ins> self.download_with_retries(&tempfile, &format!("{}/{}", base, url), help_on_error); </ins> t!(std::fs::rename(&tempfile, dest_path)); } <del> fn download_with_retries(&self, tempfile: &Path, url: &str) { </del> <ins> fn download_with_retries(&self, tempfile: &Path, url: &str, help_on_error: &str) { </ins> println!("downloading {}", url); // Try curl. If that fails and we are on windows, fallback to PowerShell. let mut curl = Command::new("curl");

Discussion:
I accidentally missed this when porting it to rustbuild: It would be nice to add it back. Mentoring instructions: Add a new parameter to and pass it down from : This code moved around in so you may want to base your changes off that PR until it lands. label +E-easy +E-mentor +A-rustbuild <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
Please also remove the dead code from at the same time:
claim
Change:
<ins> // compile-flags: -Zdrop-tracking-mir --edition=2021 #![feature(generators)] pub async fn async_bad_body() { match true {} //~ ERROR non-exhaustive patterns: type `bool` is non-empty } pub fn generator_bad_body() { || { // 'non-exhaustive pattern' only seems to be reported once, so this annotation doesn't work // keep the function around so we can make sure it doesn't ICE match true {}; // ERROR non-exhaustive patterns: type `bool` is non-empty yield (); }; } 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. --<!-- 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
regression in cc
Hmm, I guess that before this function just received broken MIR and carried on, but exited due to the HIR errors without trying to dump it. Now that we return an error body for broken code we're getting a panic
Change:
}; libc::dlsym(libc::RTLD_DEFAULT, name.as_ptr()) as usize } <ins> #[cfg(not(target_os = "linux"))] macro_rules! syscall { (fn $name:ident($($arg_name:ident: $t:ty),*) -> $ret:ty) => ( unsafe fn $name($($arg_name: $t),*) -> $ret { use libc; use super::os; weak! { fn $name($($t),*) -> $ret } if let Some(fun) = $name.get() { fun($($arg_name),*) } else { os::set_errno(libc::ENOSYS); -1 } } ) } #[cfg(target_os = "linux")] macro_rules! syscall { (fn $name:ident($($arg_name:ident: $t:ty),*) -> $ret:ty) => ( unsafe fn $name($($arg_name:$t),*) -> $ret { // This looks like a hack, but concat_idents only accepts idents // (not paths). use libc::*; syscall( concat_idents!(SYS_, $name), $($arg_name as c_long),* ) as $ret } ) } </ins>

Discussion:
Sorry for the cryptic title, didn't knew exactly what to put there. On musl targets (well and (hf)) for some reason pipe2 is not used (even on kernels that support it). Pipe2 is important to protect against race condition when multiple threads run external commands. The following is an example that due to this bug will deadlock on the musl targets listed above (and probably all linux musl ones). Running with strace proves that pipe2 is not used, and that instead the fallback is: vs the target: Versions affected: 1.30.1 1.31.0 - Current stable rustc 1.32.0-nightly ( 2018-12-07) Later Edit: Just to be clear, if I compile a C file with the same musl toolchain that rust uses pipe2 works, so it's not a bug in Musl (or doesn't look like one to me).
cc
Did some investigation regarding this bug: The culprit seems to be: More specifically the following comment: “It assumes that //! we've been dynamically linked to the library the symbol comes from, but that //! is currently always the case for things like libpthread/libc.” Well this is not the case for musl target binaries. pipe2 is one of the symbols rust uses this mechanism to check for existence.(for fair reasons, the symbol is not there on old kernels). But on any musl target this symbol does exist because musl is emulating it in it’s standard library in case the systemcall is missing. A solution would thus be to assume this symbol always exists on musl targets (and it’s probably the same for the other ones) and make the weak! macro return the symbol directly for such targets. I could do it myself if this sounds resonable.
Thanks for the report Your investigation sounds right to me and I agree that we can probably just assume these symbols always exist on the musl target (as we're mostly pulling in the libc anyway). Should be fine to update the standard library to assume so!
Is this kind of what you had in mind? I wanna know if I should go like this, or I understood you wrong.
Change:
} Stdio::MakePipe => { <del> let (reader, writer) = pipe::anon_pipe()?; let (ours, theirs) = if stdio_id == c::STD_INPUT_HANDLE { (writer, reader) } else { (reader, writer) }; *pipe = Some(ours); </del> <ins> let ours_readable = stdio_id != c::STD_INPUT_HANDLE; let pipes = pipe::anon_pipe(ours_readable)?; *pipe = Some(pipes.ours); </ins> cvt(unsafe { <del> c::SetHandleInformation(theirs.handle().raw(), </del> <ins> c::SetHandleInformation(pipes.theirs.handle().raw(), </ins> c::HANDLE_FLAG_INHERIT, c::HANDLE_FLAG_INHERIT) })?; <del> Ok(theirs.into_handle()) </del> <ins> Ok(pipes.theirs.into_handle()) </ins> } Stdio::Handle(ref handle) => {

Discussion:
It looks like the use of overlapped I/O on stdio ports may cause some problems in Windows. When I try to shell out to using on the stderr port, the command runs successfully but hangs at the end. pointed me to this commit as the likely culprit: Here's the smallest test case I could figure out how to create: I wanted to try to come up with a minimal Node script to shell out to, as opposed to . Unfortunately, I'm not good enough at debugging npm and Node to figure out exactly what they're doing that causes the hang.
Ok I've tested this and it's a stable-to-stable regression that happened between 1.8 and 1.9. I believe the 1.9 release is indeed the first one with , the likely change which is a culprit. Tagging appropriately as such.
It looks like Rust is passing overlapped-mode pipe handles to the child process. The function returns two overlapped HANDLES. I'm not sure the overlapped mode can be changed after the fact -- maybe would work -- but I don't see it used anywhere, and I'd wonder about its use on the server handle. If the child inherits overlapped-mode handles, it would need to do async I/O to stdin/stdout/stderr. By convention, it does sync I/O using lpOverlapped==NULL, but that has undefined behavior if the handles are overlapped pipes. FWIW: the server and client ends of a named pipe aren't quite symmetric, but I'm guessing it doesn't matter whether the child process receives a server pipe or a client pipe? The interesting thing is that writing to a broken pipe returns , but reading from one returns . Apparently this is true for both ends. (I apparently wrote for this back in June'16.) I'd probably pass the client end to the child process, because it doesn't make sense that a program can call DisconnectNamedPipe on its stdio handles. (DisconnectNamedPipe doesn't work on client handles.) I made a Rust + C++ test case demonstrating how passing overlapped handles to the child breaks:
Fascinating! Thanks for the links That perfectly explains I think what's going on here. I think I can see the fix here, so I'll work on that pronto.
Yeah, I think the fix is easy -- use non-overlapped handles for the child but overlapped handles for the parent.
Change:
--> $DIR/missing_arguments.rs:39:3 | LL |   complex(   1,                     ""   ); <del> |   ^^^^^^^--------------------------------- three arguments of type `f32`, `i32`, and `i32` are missing </del> <ins> |   ^^^^^^^--------------------------------- three arguments of type `f32`, `i32`, and `f32` are missing </ins> | note: function defined here --> $DIR/missing_arguments.rs:7:4

Discussion:
: <!-- 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 --
Also ICEs on beta. Output on stable: label regression-from-stable-to-beta
searched nightlies: from nightly-2022-04-16 to nightly-2022-04-17 regressed nightly: nightly-2022-04-17 searched commit range: regressed commit: <details<summarybisected with <a href=''cargo-bisect-rustc</av0.6.3</summaryHost triple: x86_64-unknown-linux-gnu Reproduce with: </detailscc
claim
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-medium