Rollup of 8 pull requests #50775
Closed
Rollup of 8 pull requests #50775
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
Previously, every `open64` was accompanied by a `ioctl(…, FIOCLEX)`, because some old Linux version would ignore the `O_CLOEXEC` flag we pass to the `open64` function. Now, we check whether the `CLOEXEC` flag is set on the first file we open – if it is, we won't do extra syscalls for every opened file. If it is not set, we fall back to the old behavior of unconditionally calling `ioctl(…, FIOCLEX)` on newly opened files. On old Linuxes, this amounts to one extra syscall per process, namely the `fcntl(…, F_GETFD)` call to check the `CLOEXEC` flag. On new Linuxes, this reduces the number of syscalls per opened file by one, except for the first file, where it does the same number of syscalls as before (`fcntl(…, F_GETFD)` to check the flag instead of `ioctl(…, FIOCLEX)` to set it).
It was introduced in rust-lang#50240 to avoid an allocation when creating a new BTreeMap, which gave some speed-ups. But then rust-lang#50352 made that the default behaviour for BTreeMap, so LazyBTreeMap is no longer necessary.
Unblocking PRs: - rust-lang/cargo#5535 - Ignore <tab> in libtest output. (unblocks rust-lang#50387) - rust-lang/cargo#5537 - Remove -Zno-trans test. (unblocks rust-lang#50615) - rust-lang/cargo#5540 - Fix tests when CARGO_TARGET_DIR is set. (unblocks self) Regression fixes: - rust-lang/cargo#5503 - cargo rustc broken for tests in project with bins - rust-lang/cargo#5520 - (rust-lang#50640) shared proc-macro dependency built incorrectly Changes: - rust-lang/cargo#5527 - Point Source Replacement to the Overriding Dependencies section - rust-lang/cargo#5533 - Detail how to run locally-built nightly cargo - rust-lang/cargo#5522 - Add option to set user-agent - rust-lang/cargo#5519 - NFC: fix a couple of typos, found by codespell. - rust-lang/cargo#5513 - Fix `panic` for binaries built during tests. - rust-lang/cargo#5512 - simplify build_requirements - rust-lang/cargo#5301 - Add --build-plan for 'cargo build' - rust-lang/cargo#5460 - Be more conservative about which files are linked to the output dir. - rust-lang/cargo#5509 - Use the new stable - rust-lang/cargo#5507 - Does not print seconds fraction with minutes - rust-lang/cargo#5498 - Bump to 0.29.0 - rust-lang/cargo#5497 - Mention +nightly in ARCHITECTURE.md
Add simd math intrinsics and gather/scatter This PR adds simd math intrinsics for floating-point vectors (sqrt, sin, cos, pow, exp, log, fma, abs, etc.) and the generic simd gather/scatter intrinsics.
…uillaumeGomez rustdoc: replace most (e)println! statements with structured warnings/errors Turns out, the rustc diagnostic handler doesn't need a whole lot of setup that we weren't already doing. For errors that occur outside a "dealing with source code" context, we can just use the format/color config we were already parsing and make up a `Handler` that we can emit structured warnings/errors from. So i did that. This will make it way easier to test things with `rustdoc-ui` tests, since those require the JSON error output. (In fact, this PR is a yak shave for a different one where i was trying to do just that. `>_>`)
Don't unconditionally set CLOEXEC twice on every fd we open on Linux Previously, every `open64` was accompanied by a `ioctl(…, FIOCLEX)`, because some old Linux version would ignore the `O_CLOEXEC` flag we pass to the `open64` function. Now, we check whether the `CLOEXEC` flag is set on the first file we open – if it is, we won't do extra syscalls for every opened file. If it is not set, we fall back to the old behavior of unconditionally calling `ioctl(…, FIOCLEX)` on newly opened files. On old Linuxes, this amounts to one extra syscall per process, namely the `fcntl(…, F_GETFD)` call to check the `CLOEXEC` flag. On new Linuxes, this reduces the number of syscalls per opened file by one, except for the first file, where it does the same number of syscalls as before (`fcntl(…, F_GETFD)` to check the flag instead of `ioctl(…, FIOCLEX)` to set it).
Update Cargo Unblocking PRs: - rust-lang/cargo#5535 - Ignore <tab> in libtest output. (unblocks rust-lang#50387) - rust-lang/cargo#5537 - Remove -Zno-trans test. (unblocks rust-lang#50615) - rust-lang/cargo#5540 - Fix tests when CARGO_TARGET_DIR is set. (unblocks self) Regression fixes: - rust-lang/cargo#5503 - cargo rustc broken for tests in project with bins - rust-lang/cargo#5520 - (rust-lang#50640) shared proc-macro dependency built incorrectly Changes: - rust-lang/cargo#5527 - Point Source Replacement to the Overriding Dependencies section - rust-lang/cargo#5533 - Detail how to run locally-built nightly cargo - rust-lang/cargo#5522 - Add option to set user-agent - rust-lang/cargo#5519 - NFC: fix a couple of typos, found by codespell. - rust-lang/cargo#5513 - Fix `panic` for binaries built during tests. - rust-lang/cargo#5512 - simplify build_requirements - rust-lang/cargo#5301 - Add --build-plan for 'cargo build' - rust-lang/cargo#5460 - Be more conservative about which files are linked to the output dir. - rust-lang/cargo#5509 - Use the new stable - rust-lang/cargo#5507 - Does not print seconds fraction with minutes - rust-lang/cargo#5498 - Bump to 0.29.0 - rust-lang/cargo#5497 - Mention +nightly in ARCHITECTURE.md
read2: Use inner function instead of closure Very minor thing, but there doesn't appear to be a reason to use a closure here. Generated code is identical in my tests, but I believe it's clearer that nothing from the environment is being used.
…ertj Remove LazyBTreeMap. It was introduced in rust-lang#50240 to avoid an allocation when creating a new BTreeMap, which gave some speed-ups. But then rust-lang#50352 made that the default behaviour for BTreeMap, so LazyBTreeMap is no longer necessary.
…ibsyntax-ext, r=frewsxcv Add missing error codes in libsyntax-ext asm
Don't inject clippy into the rls anymore r? @kennytm sorry about breaking nightlies. The issue is that the `[patch.crates-io]` doesn't work if the versions differ. So every time we update clippy, we can only update it to the verison that rls is depending on. I'm disabling the injection of clippy into rls for now. I'm not sure how to do this properly. We could * add a version check, so rls only builds clippy if its dependency clippy is the same as the submodule clippy * do something crazy like auto-patching the Cargo.toml of the rls tool repo to just use a path dependency on clippy * build crates-io clippy instead of submodule clippy and gate clippy injection on that * that's somewhat automatic, and is essentially what is necessary right now, but done manually * make clippy 0.1.* instead of 0.0.* and update patch versions for nightly updates and minor version updates for `clippy_lints` api changes. * not sure how semver-great this is
|
(rust_highfive has picked a reviewer for you, use r? to override) |
|
|
rust-highfive
added
the
S-waiting-on-review
|
@bors r+ p=8 |
|
📌 Commit e74f5e8 has been approved by |
bors
added
S-waiting-on-bors
|
⌛ Testing commit e74f5e8 with merge f451a432daf373c526fe3ee2d1ba6a5a99894415... |
|
💔 Test failed - status-travis |
bors
added
S-waiting-on-review
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
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.
Successful merges:
Failed merges: