jiebi/CodeConvo huggingface dataset:
Change:
builder.ensure(TestHelpers { target: compiler.host }); // ensure that `libproc_macro` is available on the host. <del> builder.ensure(compile::Std::new(compiler, compiler.host)); </del> <ins> if suite == "mir-opt" { builder.ensure(compile::Std::new_for_mir_opt_tests(compiler, compiler.host)); } else { builder.ensure(compile::Std::new(compiler, compiler.host)); } </ins> // As well as the target if suite != "mir-opt" {

Discussion:
Using , running causes bootstrap to rebuild all of std before running the tests, even when the build cache ought to be warm from a previous . Needless to say, this is not very fun when actually trying to run one or more mir-opt tests.
cc
I will note that does seem to avoid the rebuild when re-running the tests.
Is there some way for CI to error on spurious rebuilds? I don't know what that would look like but this has happened in a few different places for different reasons so it'd be nice if there were some way to catch it early.
Usually the spurious rebuilds happen if you try to run the same command, twice. I don't think that's very tractable for CI, but am happy to be proven wrong. Maybe we can try to devise some kind of mechanism in bootstrap to make some invalidations impossible, but I don't know how such a mechanism would work in general.
One mechanism for that would be to keep the rustflags logic in a single sealed module, so they can't be set externally from the individual build steps, which means they can't invalidate the build cache. Next to that approach we can add test coverage to rustflags logic.
I opened a short-term immediate fix in , but the long term solution to prevent resurrgence of -induced invalidation is a proper prevention mechanism as described above.
Also this one actually builds same stage std twice for host if host == target (i.e. not cross-compile) because std was 'd twice with differing . The double std build was the dead giveaway that fortunately makes it very easy to tell what the rebuild was caused by.
Change:
<ins> // check-pass /// [`…foo`] [`…bar`] [`Err`] pub struct Broken {} /// [`…`] [`…`] [`Err`] pub struct Broken2 {} /// [`…`][…] [`…`][…] [`Err`] pub struct Broken3 {} /// […………………………][Broken3] pub struct Broken4 {} /// [Broken3][…………………………] pub struct Broken5 {} pub struct Err; </ins>

Discussion:
Reduced from the source code of : <!-- 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</detailsWould have been introduced by since that PR the lint.. cc label -T-compiler +T-rustdoc
Change:
handle }; PipeWatcher { <del> stream: StreamWatcher::new(handle), </del> <ins> stream: StreamWatcher::new(handle, true), </ins> home: home, defused: false, refcount: Refcount::new(),

Discussion:
When using libgreen on Windows (verified not to occur with libnative) when I'm reading from a TcpStream and the remote host closes the stream (specifically I'm closing the client by pressing ctrl + c), the server silently terminates with no error messages. It appears SIGSEGV is being called. The code I was writing which caused this issue can be found here: Using Windows 8.1 x64 with latest Rust nightly. Attempts to backtrace using gdb have failed:
cc
I have acquired a backtrace by attaching gdb to a running process rather than running the process from gdb to begin with (why this works I have no idea)
After debugging with visual studio I figured out the exact line causing the segfault. At it is . here is a null reference, which was transmuted from getting the data of the handle, which is apparently 0. I don't know what is setting it to 0 though.
It appears even sending packets to the connection causes it to die. Has anyone even tested libgreen on Windows with TCP?
I have determined the cause of the bug to be a race condition. Specifically every time I open up a connection, is called 3 times and is called once. If the 3 new streams all occur before the read call, the pointer remains non-zero. If one of them occurs after the read call, then the pointer becomes zero, and the read callback segfaults. I have verified this through multiple runs and statements everywhere.
To further expand, is called when a TcpStream is created, and also everytime I clone the . Since cloning a is the only way to share it across tasks (it doesn't impl ), I had to spawn two tasks, one to read and one to write. Because I spawned the reading one first it would start a read before I cloned the tcp for the writing task, and once I cloned it, the data pointer got reset so the data pointer the read callback received was null thereby causing the segfault.
Yes, no commit gets pushed to master unless it passes all tests on windows, and that includes many networking tests. Do you have a small test case which reproduces this bug? It's likely that there's just some different callback-invoking behavior on windows than on unix that was accidentally not dealt with.
Here is a minimal code example:
Change:
// the order provided to fmt::Arguments. When arguments are repeated, we // want the expression evaluated only once. // <del> // Thus in the not nicely ordered case we emit the following instead: </del> <ins> // Further, if any arg _after the first one_ contains a yield point such // as `await` or `yield`, the above short form is inconvenient for the // caller because it would keep a temporary of type ArgumentV1 alive // across the yield point. ArgumentV1 can't implement Send since it // holds a type-erased arbitrary type. // // Thus in the not nicely ordered case, and in the yielding case, we // emit the following instead: </ins> // //     match (&$arg0, &$arg1, …) { //         args => [ArgumentV1::new(args.$i, …), ArgumentV1::new(args.$j, …), …] //     } // // for the sequence of indices $i, $j, … governed by fmt_arg_index_and_ty. <ins> // This more verbose representation ensures that all arguments are // evaluated a single time each, in the order written by the programmer, // and that the surrounding future/generator (if any) is Send whenever // possible. let no_need_for_match = nicely_ordered && !original_args.iter().skip(1).any(|e| may_contain_yield_point(e)); </ins> for (arg_index, arg_ty) in fmt_arg_index_and_ty { let e = &mut original_args[arg_index]; let span = e.span; <del> let arg = if nicely_ordered { </del> <ins> let arg = if no_need_for_match { </ins> let expansion_span = e.span.with_ctxt(self.macsp.ctxt()); // The indices are strictly ordered so e has not been taken yet. self.ecx.expr_addr_of(expansion_span, P(e.take()))

Discussion:
This has already tripped up some people which seem to get quite confused with this error message, so I'd rather we not regress here: I tried this code: I expected to see this happen: Code compiles fine: the type of is . Instead, this happened: The type of is not send, since the backing state-machine generator produced for it now captures part of the internals involving a reference to the , which is not . It most recently worked on: beta : modify labels: +regression-from-stable-to-nightly -regression-untriaged
Might be related to / ?
I was also suspecting one of those, although I have to admit not having looked into it any further
Does it work with btw ? That should completely disable drop range tracking. (I've launched a try build there so that we have artifacts ready for that soon). There were also recent changes in the formatting macros/machinery last week IIRC. That could be related as well. This should be easy enough to bisect, and make sure where the regression is coming from.
Answering my own questions: doesn't change this, my guess is that it's actually unrelated to initially landed as part of and that rollup's commit doesn't reproduce the issue the change I mentioned was and its commit does reproduce the issue. This PR seems to have caused it indeed.
Nice investigation
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
Change:
cmd.env("RUST_BACKTRACE", "1"); } <ins> if let Ok(lint_flags) = env::var("RUSTC_LINT_FLAGS") { cmd.args(lint_flags.split_whitespace()); } </ins> if target.is_some() { // The stage0 compiler has a special sysroot distinct from what we // actually downloaded, so we just always pass the `--sysroot` option,

Discussion:
When running two times in a row, the target as well as rls will be built again for the second even if no sources were touched.
Hm, this is an unexpected consequence of . Clippy gets built with different RUSTFLAGS, which busts the cache. I'm going to contemplate finding some way to independently cache artifacts with different RUSTFLAGS, it has come up multiple times recently. In the meantime, we may want to consider changing Clippy back to "Submodule" type so that it doesn't use different RUSTFLAGS.
I would've expected x.py build without arguments to be relatively rare as something folks are running. However, if this is an active blocker/pain point (and not just "mild annoyance"), I'm okay with adding an exception for clippy (I'd rather not change its type as that may have effects elsewhere and I wouldn't want to have to think about it every time until this is fixed). Separate caches seems reasonable, though would only contribute to perceived "bloat" of target directories I imagine.
It increases CI time because some dependencies are getting built multiple times. I compared the build just before , and it looks like it may have 18 minutes to the build time. I think it is relatively safe to change clippy to Submodule mode. The only difference is "deny warnings". The risk is that a rust-lang/rust PR introduces a new warning in the clippy code, which will have to be resolved whenever clippy is synced back to its repo. Of course it would be better to deny warnings, just tossing it out as an option. (Just to be clear, I'm not certain that's the only issue here, it will take some more investigation and testing to verify.)
Ah, so perhaps I misinterpreted -- I believe most of our CI platforms only run x.py once? (At least the longer ones, where a bump in CI times really matters). Yeah, I agree that there's not much difference to changing to submodule mode vs. explicitly gating on clippy in the warnings check, but I would prefer the later I think. I would loosely be prepared to r+ such a PR.
The cache thrashing is due to the order the tools are built.

It goes: -driver (busts cache, lots of rebuilds) (lots of rebuilds due to 3) -clippy (busts cache, lots of rebuilds) (some rebuilds due to 5) I dunno how bootstrap decides which order things get built. Is it random? I'm surprised the two clippy binaries are not done consecutively.
they are built in this order: In the past when Clippy was not always buildable I had since RLS's feature works only when Clippy can build. That's why Clippy driver is built before RLS. Reordering tools in would remove 1 rebuild, right?
Change:
#![feature(alloc_jemalloc)] extern crate allocator_dylib; <ins> // The main purpose of this test is to ensure that `alloc_jemalloc` **fails** // here (specifically the jemalloc allocator), but currently jemalloc is // disabled on quite a few platforms (bsds, emscripten, msvc, etc). To ensure // that this just passes on those platforms we link in some other allocator to // ensure we get the same error. // // So long as we CI linux/OSX we should be good. #[cfg(any(target_os = "linux", target_os = "macos"))] </ins> extern crate alloc_jemalloc; <ins> #[cfg(not(any(target_os = "linux", target_os = "macos")))] extern crate allocator1; </ins> fn main() { allocator_dylib::foo();

Discussion:
As of the time of this writing, we are running jemalloc at the revision which I believe is the 4.0.4 release of jemalloc. Previously we were running which I believe is somewhere in the 3.6 series. We attempted to upgrade jemalloc many times between these two commits eventually that the previous behavior of on Windows is fundamentally racy in jemalloc right now unfortunately. This led to a to where we are today. Unfortunately, however, there is a so we are attempting to downgrade back to 3.6. There were no known problems other than some Windows issues with jemalloc 3.6, so we believe it'll be fine for awhile. In this downgrade, however, it appears that the implementation of is somewhat broken as well, causing the to fail to land. As a result, the downgrade attempt will disable jemalloc on Windows entirely. This issue will track re-enabling it on Windows as well as re-upgrading once the deadlock bug is fixed. As far as I know the only reason to not enable Windows is that lots of locking support was improved in 4.0.*, and the only reason to not upgrade immediately is the deadlock bugs we've encountered.
FWIW one of my Rust projects with CI-every-night has started deadlocking recently, and after some investigation it turned up the exact same stack trace as rustdoc itself, so that's at least another data point for the deadlock in jemalloc.
Change:
/// Allows creation of instances of a struct by moving fields that have /// not changed from prior instances of the same struct (RFC #2528) (unstable, type_changing_struct_update, "1.58.0", Some(86555)), <del> /// Allows using type privacy lints (`private_interfaces`, `private_bounds`, `unnameable_types`). (unstable, type_privacy_lints, "1.72.0", Some(48054)), </del> /// Enables rustc to generate code that instructs libstd to NOT ignore SIGPIPE. (unstable, unix_sigpipe, "1.65.0", Some(97889)), /// Allows unnamed fields of struct and union type

Discussion:
This is a tracking issue for the RFC "Type privacy and private-in-public lints " (rust-lang/rfcs). Steps: [ ] Implement the RFC (cc ) [ ] Adjust documentation ([see instructions on forge][doc-guide]) [ ] Stabilization PR ([see instructions on forge][stabilization-guide]) [stabilization-guide]: [doc-guide]: Unresolved questions: [ ] It's not fully clear if the restriction for associated type definitions required for type privacy soundness, or it's just a workaround for a technical difficulty. [ ] Interactions between macros 2.0 and the notions of reachability / effective visibility used for the lints are unclear. <!-- TRIAGEBOTSTART --<!-- TRIAGEBOTASSIGNSTART --<!-- TRIAGEBOTASSIGNDATASTARTTRIAGEBOTASSIGNDATAEND --<!-- TRIAGEBOTASSIGNEND --<!-- TRIAGEBOTEND --
claim
Oops - I didn't mean for that to un-assign you. Is there a way to prevent these lints from becoming insta-stable? Would it make sense to put them behind a feature gate?
Perhaps we could only fire the lints if an unstable compiler flag (maybe ) is passed? This would still make the lint names insta-stable, though.
in core ffi There is a fixme about , how to fixes that?
By implementing this RFC, I guess. Until that workarounds like this sealed trait will need to be used.
Where is the impl, the RFC is already accepted...
An RFC being accepted just means the feature can be implemented, not that it has been implemented. It doesn't even mean that implementing it is a priority. I believe there has been more discussion of this RFC over at as well as other issues that I can't seem to track down right now.
Hello! I know y'all are busy, but I'm curious if there's an update, particularly on for Voldemort Types - which I'd love to see. I was actually a bit surprised to find that it wasn't included in the existing lint. Appreciate the work that y'all are doing, especially who seems to have put in a lot of legwork.
The tentative plan is that will work on this in March-May.
Cool! Good luck! I'm happy to be a guinea pig to try it out or do code review if that would be helpful.
This issue should be closed by Two follow up issues about improving the effective visibility tables
Change:
<ins> macro_rules! f { ($abi:literal) => { extern $abi fn f() {} } } f!("Foo"__); //~^ ERROR suffixes on string literals are invalid 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 nightly-2022-11-18
label regression-from-stable-to-stable
WG-prioritization assigning priority (). label -I-prioritize +P-low
Change:
} let mut completed_test = res.unwrap(); <del> let running_test = running_tests.remove(&completed_test.desc).unwrap(); if let Some(join_handle) = running_test.join_handle { if let Err(_) = join_handle.join() { if let TrOk = completed_test.result { completed_test.result = TrFailedMsg("panicked after reporting success".to_string()); </del> <ins> if let Some(running_test) = running_tests.remove(&completed_test.desc) { if let Some(join_handle) = running_test.join_handle { if let Err(_) = join_handle.join() { if let TrOk = completed_test.result { completed_test.result = TrFailedMsg("panicked after reporting success".to_string()); } </ins> } } }

Discussion:
Hi, When running doc-tests with the latest Nightly on my crate, I get an ICE after the first doc-test is executed twice in a row. The issue does not occur on Stable. The issue seems to be caused when multiple threads are used for doc-tests. The ICE is caused by in . The issue occured on the and targets. Curiously, there are multiple targets on which it does not occur (according to Travic CI builds). The Travis CI build status is available here : . the repo for the ; commit ; either or . The actual number of threads does not seem to matter as long as there is more than one. In my case, specifying was not necessary, since I think the number of threads is determined automatically in this case. : <!-- Include a backtrace in the code block by setting in your environment. E.g. . --<details<summary<strongBacktrace</strong</summary<p</p</details
This is now a regression from stable to beta.
Bisection says the regression happened in . label -E-needs-bisection
cc do you have time to take a look?
It seems like the underlying problem is that it’s possible for different tests to collide to the same when macros are involved. Minimal example: /// asserteq!(1, 1); /// /// asserteq!(1, 1); /// Before , this produced and now it panics. We should fix the underlying problem, but a simple band-aid for beta would be to turn the into an . The only side effect would be that we don’t get the benefits of in the presence of these collisions.
I’ve submitted that workaround as .
Change:
let b_ptr = self.bitcast(b, i8p_ty); let n = self.const_usize(layout.size().bytes()); let cmp = self.call_intrinsic("memcmp", &[a_ptr, b_ptr, n]); <del> self.icmp(IntPredicate::IntEQ, cmp, self.const_i32(0)) </del> <ins> match self.cx.sess().target.arch.as_str() { "avr" | "msp430" => self.icmp(IntPredicate::IntEQ, cmp, self.const_i16(0)), _ => self.icmp(IntPredicate::IntEQ, cmp, self.const_i32(0)), } </ins> } }

Discussion:
uses , and declares it to return i32, in reality it returns c_int, so this is a potential portability concern. Maybe memcmp can be made an intrinsic to resolve this.
It also takes a parameter, not a .
Neither of these are a practical issue (yet). crate libc does not support any other configuration than so far.
cc
The extern function is now in
What should we do next? Should we try to create a intrinsic?
Hi, I believe this issue is causing array comparisons on the AVR architecture to break (see the linked issue, ). Is there any consensus on a path forward here?
Change:
return; } <del> add_dylib_path(vec![self.rustc_libdir(compiler)], &mut cmd.command); </del> <ins> add_dylib_path(vec![self.rustc_libdir(compiler)], cmd); </ins> } /// Gets a path to the compiler specified.

Discussion:
I tried to build rust right after got merged and caught error:
cc
What command did you run?
Change:
} env::join_paths(paths.iter()).unwrap() }); <ins> cmd.env("LC_ALL", "C"); // force english locale </ins> if is_windows() { let mut paths = vec![];

Discussion:
On an non-English system the run-make test fails because it searches a english "needle" but may print it in another language. Putting in my environment variable makes use it's default (English) language. We should probably do that for all the run-make tests.
... good catch. I love C locale.
In the compiler we set and before calling linker because we inspect linker output sometimes. That said, isn't the plan to migrate operations like this from third-party tools to library calls to something like ?
It is. However, my current plan is to prioritize first getting rid of and trimming down external bin tools and deps where possible (some of them are first moved to llvm bintools which are at least batched together with llvm). It's non-trivial to match readelf/readobj etc. when they have various combination of flags, and when reviewing I found out that libraries like have differences in its interpretation of symbols (i.e. they don't match cleanly 1-to-1). Getting rid of first of all means that we can run the run-make tests outside of msys2 msys lol. I'm going to do a second pass after first getting rid of , and revisit things like: External bin tools. Tests that require bootstrap cargo and then internet connection to run the test (the target sanity check tests). TL;DR: yes, eventually.