minor: Sync from downstream #18874
Merged
minor: Sync from downstream #18874
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Automatic Rustup
Automatic Rustup
Enable native libraries on macOS Fixes rust-lang#3595 by using `-fvisibility=hidden` and the visibility attribute supported by both gcc and clang rather than the previous gcc-only mechanism for symbol hiding. Also brings over cfg changes from rust-lang#3594 which enable native-lib functionality on all unixes. Thanks for taking a look, feedback very welcome! cc `@RalfJung`
…alfJung Detect when pthread_mutex_t is moved What I am not sure about this PR is how to support storing the additional mutex data like its address and kind. If I understand correctly the `concurrency::sync::Mutex` struct is to be used by any mutex implementation. This possibly means that different implementation might want to store different data in the mutex. So any additional data should be implementation defined somehow. Solutions that come to mind: - Store the additional data as `Box<dyn Any>` and the implementations can downcast their data when they fetch them. - Have each shim implementation define a `static mut` map between `MutexID`s and the additional data. Let me know Fixes rust-lang#3749
Automatic Rustup
Fix tokio test ICE Fixes rust-lang#3858 It turned out that the issue mentioned [here](rust-lang/miri#3858 (comment)) is the exact cause of ICE. So in this PR, I changed the type of ``EpollEventInterest::epfd`` from ``i32`` to ``WeakFileDescriptionRef``.
Refactor fd read/write This PR passed the responsibility of reading to user supplied buffer and dest place to each implementation of ``FileDescription::read/write/pread/pwrite``. This is part of rust-lang#3665.
Automatic Rustup
…fJung Added a variadic argument helper `@RalfJung,` as you wished (:
Automatic Rustup
Replace set_last_error with set_last_error_and_return Took care of the simple patterns. Other patterns involved setting an error and then using `write_int` or setting metadata and returning -1. Unsure if those are in the scope of this change Looks like this has conflicts with rust-lang#3779, so I can update when how to handle that is decided. Part of rust-lang/miri#3930.
Android: Added support for prctl handling thread names Addresses the first part of rust-lang#3618.
Switch CI to merge queues
Automatic Rustup
Change futex_wait errno from Scalar to IoError
Automatic Rustup
…, r=wesleywiser" This reverts commit 1d35638dc38dbfbf1cc2a9823135dfcf3c650169, reversing changes made to f23a80a4c2fbca593b64e70f5970368824b4c5e9.
Revert stabilization of the `#[coverage(..)]` attribute Due to a process mixup, the PR to stabilize the `#[coverage(..)]` attribute (#130766) was merged while there are still outstanding concerns. The default action in that situation is to revert, and the feature is not sufficiently urgent or uncontroversial to justify special treatment, so this PR reverts that stabilization. --- - A key point that came up in offline discussions is that unlike most user-facing features, this one never had a proper RFC, so parts of the normal stabilization process that implicitly rely on an RFC break down in this case. - As the implementor and de-facto owner of the feature in its current form, I would like to think that I made good choices in designing and implementing it, but I don't feel comfortable proceeding to stabilization without further scrutiny. - There hasn't been a clear opportunity for T-compiler to weigh in or express concerns prior to stabilization. - The stabilization PR cites a T-lang FCP that occurred in the tracking issue, but due to the messy design and implementation history (and lack of a clear RFC), it's unclear what that FCP approval actually represents in this case. - At the very least, we should not proceed without a clear statement from T-lang or the relevant members about the team's stance on this feature, especially in light of the other concerns listed here. - The existing user-facing documentation doesn't clearly reflect which parts of the feature are stable commitments, and which parts are subject to change. And there doesn't appear to be a clear consensus anywhere about where that line is actually drawn, or whether the chosen boundary is acceptable to the relevant teams and individuals. - For example, the [stabilization report comment](rust-lang/rust#84605 (comment)) mentions that some aspects are subject to change, but that text isn't consistent with my earlier comments, and there doesn't appear to have been any explicit discussion or approval process. - [The current reference text](https://github.com/rust-lang/reference/blob/4dfaa4f/src/attributes/coverage-instrumentation.md) doesn't mention this distinction at all, and instead simply describes the current implementation behaviour. - When the implementation was changed to its current form, the associated user-facing error messages were not updated, so they still refer to the attribute only being allowed on functions and closures. - On its own, this might have been reasonable to fix-forward in the absence of other concerns, but the fact that it never came up earlier highlights the breakdown in process that has occurred here. --- Apologies to everyone who was excited for this stabilization to land, but unfortunately it simply isn't ready yet.
Rollup of 4 pull requests Successful merges: - #129220 (Add platform docs for FreeBSD.) - #134659 (test-infra: improve compiletest and run-make-support symlink handling) - #134668 (Make sure we don't lose default struct value when formatting struct) - #134672 (Revert stabilization of the `#[coverage(..)]` attribute) r? `@ghost` `@rustbot` modify labels: rollup
Subtree update of `rust-analyzer` r? `@ghost`
Use `#[derive(Default)]` instead of manual `impl` when possible While working on #134175 I noticed a few manual `Default` `impl`s that could be `derive`d instead. These likely predate the existence of the `#[default]` attribute for `enum`s.
opt-dist: propagate channel info to bootstrap Fixes #133503. Previously, `tests/ui/bootstrap/rustc_bootstap.rs` [sic] failed during [beta bump](rust-lang/rust#133447 (comment)) in opt-dist tests. This is because: - `opt-dist` tried to run `./x test` against beta-channel dist `rustc` through `bootstrap`. - The dist build produced during the beta bump produces a `rustc` which correctly thinks that it is a beta compiler based on `src/ci/channel` info. - `opt-dist` tries to run `./x test` on the beta `rustc` from the dist build, but without specifying channel through a synthetic `config.toml`, so `bootstrap` tells `compiletest` that we're on the `nightly` channel (by default). - Now there's a channel mismatch: `compiletest` believes the `rustc` under test is a *nightly* rustc, but the `rustc` under test actually considers itself a *beta* rustc. This means that `//@ only-nightly` will be satisfied yet the test will fail as the *beta* rustc is not a *nightly* rustc. This PR: - Fixes the test failure during beta bump (i.e. #133503) by having `opt-dist` faithfully report the channel of the dist `rustc` being tested (i.e. "beta" in a beta bump PR). This will properly make the test be ignored during beta bump as the `rustc` under test is not a *nightly* rustc. - Fixes the test name `rustc_bootstap.rs` -> `rustc_bootstrap.rs`. No more stapping. - Slightly adjusts the doc comment in the test to make it more clear. I ran a try-job against the beta branch (explicitly running the opt-dist tests by modifying the job definition) with these changes in #134131, and it appears that the try-job was [successful](rust-lang/rust#134131 (comment)). The two commits in this PR are cherry-picked from #134131, with the test commit slightly modified (to also adjust the test comments). r? `@Kobzol` (or compiler or bootstrap or infra I guess?)
Document the `--dev` flag for `src/ci/docker/run.sh` This flag is very helpful for debugging CI issues locally, but it's not documented anywhere and I wasn't aware of it until `@jieyouxu` pointed it out. Add a note to the CI Docker readme to make this more discoverable
Clean up a few rmake tests Now I'm aware it's a bit late to start participating in the Advent of Tests, but here are a few cleanups in the rmake tests to put under the 🎄 anyways. A handful of unused imports, some warnings, and a couple typos. r? `@jieyouxu` 🎅
Rollup of 5 pull requests Successful merges: - #134363 (Use `#[derive(Default)]` instead of manual `impl` when possible) - #134517 (Add tests for coverage attribute on trait functions) - #134528 (opt-dist: propagate channel info to bootstrap) - #134669 (Document the `--dev` flag for `src/ci/docker/run.sh`) - #134680 (Clean up a few rmake tests ) r? `@ghost` `@rustbot` modify labels: rollup
Generate shell completions for x as well It would be nice to be have shell completions for both `./x` and `x` (installed with `cargo install --path src/tools/x`) instead of just `x.py`. This pr generates the corresponding completions for each shell in a similar way to `x.py` but under `x.<shell>` instead.
Begin to implement type system layer of unsafe binders Mostly TODOs, but there's a lot of match arms that are basically just noops so I wanted to split these out before I put up the MIR lowering/projection part of this logic. r? oli-obk Tracking: - rust-lang/rust#130516
Fix some typos
improve type mutation for certain structures self-explanatory
Bump `stdarch` This bumps `stdarch` to rust-lang/stdarch@684de0d to get in rust-lang/stdarch#1677 (tracked in rust-lang/rust#133908). From the [commit history](rust-lang/stdarch@e5e00aa...684de0d) I deduced that there shouldn't be any changes to Rust necessary. From past PRs I'm assuming that bumping `stdarch` like this is fine, but please let me know if this is somehow inappropriate or requires something more to be done! try-job: arm-android try-job: armhf-gnu
…eGomez nits: Cleanup of `librustdoc::clean::Cfg::simplify_with` r? `@GuillaumeGomez`
Miri subtree update r? `@ghost`
fix default-backtrace-ice test when running `tests/ui/panics/default-backtrace-ice.rs locally it gave this error: ``` failures: ---- [ui] tests/ui/panics/default-backtrace-ice.rs stdout ---- Saved the actual stderr to "/home/jyn/src/rust3/build/x86_64-unknown-linux-gnu/test/ui/panics/default-backtrace-ice/default-backtrace-ice.stderr" diff of stderr: 7 8 aborting due to `-Z treat-err-as-bug=1` 9 stack backtrace: - (end_short_backtrace) - (begin_short_backtrace) - (end_short_backtrace) - (begin_short_backtrace) + [... omitted 22 frames ...] + ``` (note that you must *not* use --bless; we previously did not have an error annotation to verify it was a full backtrace instead of a short backtrace.) this is a regression from setting RUST_BACKTRACE=1 by default in rust-lang/rust#134743. we need to turn off the new behavior when running UI tests so that they reflect our dist compiler. normally that's done by checking `sess.unstable_opts.ui_testing`, but this happens extremely early in the compiler before we've expanded arg files. do an extremely simple hack that doesn't work in all cases - we don't need it to work in all cases, only when running UI tests. cc rust-lang/rust#129658 (comment) r? `@jieyouxu`
Unify fs::copy and io::copy on Linux Currently, `fs::copy` first tries a regular file copy (via copy_file_range) and then falls back to userspace read/write copying. We should use `io::copy` instead as it tries copy_file_range, sendfile, and splice before falling back to userspace copying. This was discovered here: SUPERCILEX/fuc#40 Perf impact: `fs::copy` will now have two additional statx calls to decide which syscall to use. I wonder if we should get rid of the statx calls and only continue down the next fallback when the relevant syscalls say the FD isn't supported.
replace bootstrap-self-test feature flag with cfg(test) This makes it in more rusty way.
Avoid ICE in borrowck Provide a fallback in `best_blame_constraint` when `find_constraint_paths_between_regions` doesn't have a result. This code is due a rework to avoid the letf-over `unwrap()`, but avoids the ICE caused by the repro. Fix #133252.
Avoid short writes in LineWriter If the bytes written to `LineWriter` contains at least one new line but doesn't end in a new line (e.g. `"abc\ndef"`) then we: - write up to the last new line direct to the underlying `Writer`. - copy as many of the remaining bytes as will fit into our internal buffer. That last step is inefficient if the remaining bytes are larger than our buffer. It will needlessly split the bytes in two, requiring at least two writes to the underlying `Writer` (one to flush the buffer, one more to write the rest). This PR skips the extra buffering if the remaining bytes are larger than the buffer.
Pass the arch rather than full target name to windows_registry::find_tool The full target name can be anything with custom target specs. Passing just the arch wasn't possible before cc 1.2, but is now thanks to rust-lang/cc-rs#1285. try-job: i686-msvc
rustbot
added
the
S-waiting-on-review
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.