Update/nightly 2021 10 29 #106
Closed
Conversation
This file contains hidden or 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
Rollup of 7 pull requests Successful merges: - #88895 (rustdoc: Cleanup `clean` part 2) - #88973 (Expose the std_detect env_override feature) - #89010 (Add some intra doc links) - #89198 (rustdoc: Don't show hidden trait methods) - #89216 (Consistent big O notation) - #89224 (Change the order of imports suggestions) - #89256 (Fix typo in release notes) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Validate builtin attributes for macro args. This adds some validation for `path`, `crate_type`, and `recursion_limit` attributes so that they will now return an error if you attempt to pass a macro into them (such as `#[path = foo!()]`). Previously, the attribute would be completely ignored. These attributes are special because their values need to be known before/during expansion. cc #87681
…mulacrum Support incremental in compiletest for non-incremental modes. This adds first-class support for using incremental builds in non-incremental-mode tests. These tests previously manually passed `-C incremental=tmp/foo` which resulted in reusing the same tmp folder between runs. This means that these tests could fail whenever the on-disk incremental format changed (such as when updating one's local source tree). This changes it so that these tests can pass a `// incremental-build` header which instructs compiletest to create a set aside a dedicated incremental directory which will be cleared before the test starts to ensure it has a clean slate.
Remove most box syntax uses from the testsuite except for src/test/ui/issues Removes most box syntax uses from the testsuite outside of the src/test/ui/issues directory. The goal was to only change tests where box syntax is an implementation detail instead of the actual feature being tested. So some tests were left out, like the regression test for #87935, or tests where the obtained error message changed significantly. Mostly this replaces box syntax with `Box::new`, but there are some minor drive by improvements, like formatting improvements or `assert_eq` instead of `assert!( == )`. Prior PR that removed box syntax from the compiler and tools: #87781
Previously, only the raw string and the `is_ignore` field were preserved, which made it hard to recover anything else.
Previously it would unconditionally use edition 2015, which was incorrect.
2229: Mark insignificant dtor in stdlib I looked at all public [stdlib Drop implementations](https://doc.rust-lang.org/stable/std/ops/trait.Drop.html#implementors) and categorized them into Insigificant/Maybe/Significant Drop. Reasons are noted here: https://docs.google.com/spreadsheets/d/19edb9r5lo2UqMrCOVjV0fwcSdS-R7qvKNL76q7tO8VA/edit#gid=1838773501 One thing missing from this PR is tagging HashMap as insigificant destructor as that needs some discussion. r? `@Mark-Simulacrum` cc `@nikomatsakis`
Turns out, this has some really bad perf implications in large types (issue #88862). While we technically can handle them fine, it doesn't change test output either way. For now, revert with an added benchmark. Future attempts to change this back will have to consider perf.
Sync rustc_codegen_cranelift Nothing exciting this time. Mostly internal refactorings. r? `@ghost` `@rustbot` label +A-codegen +A-cranelift +T-compiler
Stop suggesting a float truncation that is not shorter Fixes #7721. Previously Clippy would say that a number has excessive precision even if it has the minimum possible precision for the floating point value that it corresponds to. changelog: Fix [`excessive_precision`] being triggered on floats that are already written in shortest form
Update stdarch submodule This is mainly to fix the critical issue of aarch64 store intrinsics overwriting additional memory, see rust-lang/stdarch#1220 Changes: * aarch64/armv7: additional vld1/vst1 intrinsics + perf fixes for existing ones * rust-lang/stdarch#1205 * rust-lang/stdarch#1207 * rust-lang/stdarch#1216 * armv7: Make FMA work with vfpv4 and optimize * rust-lang/stdarch#1219 * Non-visible changes to the testing framework * rust-lang/stdarch#1208 * rust-lang/stdarch#1211 * rust-lang/stdarch#1213 * rust-lang/stdarch#1215 * rust-lang/stdarch#1218
Fixed types Add checks for rustup and if toolchain is linked Fortified rustup/directory checks; made other suggested changes Added check for output status Remove output of rustup from console Made suggested change Deleted confusing comment Fixed compiler error; removed extra declaration Refactored to smaller components; made suggested changes Automate toolchain linking for stage 1 builds
…rk-Simulacrum Simplify explicit request check and allow to run "doc src/librustdoc" even without config set Originally I wanted to allow the command `doc src/librustdoc` to work when passed explicitly but then `@Mark-Simulacrum` recommended me to generalize it, so here we are! r? `@Mark-Simulacrum`
Clean up clean/types.rs file by making the implementations follow the type declaration This PR doesn't change anything, it simply moves things around: when reading the code, I realized a few times that a type declaration and implementations on it might be separated by some other type declarations, which makes the reading much more complicated. I put back impl and declaration together. r? `@camelid`
As per the libs team decision in #58935. Closes #58935
Optimize VecDeque::append Optimize `VecDeque::append` to do unsafe copy rather than iterating through each element. On my `Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz`, the benchmark shows 37% improvements: ``` Master: custom-bench vec_deque_append 583164 ns/iter custom-bench vec_deque_append 550040 ns/iter Patched: custom-bench vec_deque_append 349204 ns/iter custom-bench vec_deque_append 368164 ns/iter ``` Additional notes on the context: this is the third attempt to implement a non-trivial version of `VecDeque::append`, the last two are reverted due to unsoundness or regression, see: - rust-lang/rust#52553, reverted in rust-lang/rust#53571 - rust-lang/rust#53564, reverted in rust-lang/rust#54851 Both cases are covered by existing tests. Signed-off-by: tabokie <[email protected]>
Avoid allocations and copying in Vec::leak The [`Vec::leak`] method (#62195) is currently implemented by calling `Vec::into_boxed_slice` and `Box::leak`. This shrinks the vector before leaking it, which potentially causes a reallocation and copies the vector's contents. By avoiding the conversion to `Box`, we can instead leak the vector without any expensive operations, just by returning a slice reference and forgetting the `Vec`. Users who *want* to shrink the vector first can still do so by calling `shrink_to_fit` explicitly. **Note:** This could break code that uses `Box::from_raw` to “un-leak” the slice returned by `Vec::leak`. However, the `Vec::leak` docs explicitly forbid this, so such code is already incorrect. [`Vec::leak`]: https://doc.rust-lang.org/stable/std/vec/struct.Vec.html#method.leak
Remove alloc::prelude As per the libs team decision in #58935. Closes #58935
…onic, r=yaahc linux/aarch64 Now() should be actually_monotonic() While issues have been seen on arm64 platforms the Arm architecture requires that the counter monotonically increases and that it must provide a uniform view of system time (e.g. it must not be possible for a core to receive a message from another core with a time stamp and observe time going backwards (ARM DDI 0487G.b D11.1.2). While there have been a few 64bit SoCs that have bugs (#49281, #56940) which cause time to not monotonically increase, these have been fixed in the Linux kernel and we shouldn't penalize all Arm SoCs for those who refuse to update their kernels: SUN50I_ERRATUM_UNKNOWN1 - Allwinner A64 / Pine A64 - fixed in 5.1 FSL_ERRATUM_A008585 - Freescale LS2080A/LS1043A - fixed in 4.10 HISILICON_ERRATUM_161010101 - Hisilicon 1610 - fixed in 4.11 ARM64_ERRATUM_858921 - Cortex A73 - fixed in 4.12 255a3f3 std: Force `Instant::now()` to be monotonic added a Mutex to work around this problem and a small test program using glommio shows the majority of time spent acquiring and releasing this Mutex. 3914a7b tries to improve this, but actually makes it worse on big systems as for 128b atomics a ldxp/stxp pair (and successful loop) for v8.4 systems that don't support FEAT_LSE2 is required which is expensive as a lock and because of how the load/store-exclusives scale on large Arm systems is both unfair to threads and tends to go backwards in performance. A small sample program using glommio improves by 70x on a 32 core Graviton2 system with this change.
remove unnecessary bound on Zip specialization impl I originally added this bound in an attempt to make the specialization sound for owning iterators but it was never correct here and the correct and [already implemented](https://github.com/rust-lang/rust/blob/497ee321af3b8496eaccd7af7b437f18bab81abf/library/alloc/src/vec/into_iter.rs#L220-L232) solution is is to place it on the IntoIter implementation.
`AbstractConst` private fields Calls `subst` in `AbstractConst::root` when `Node` is `Leaf`. r? ``@lcnr``
Stabilize feature `saturating_div` for rust 1.58.0 The tracking issue is #89381 This seems like a reasonable simple change(?). The feature `saturating_div` was added as part of the ongoing effort to implement a `Saturating` integer type (see #87921). The implementation has been discussed [here](rust-lang/rust#87921 (comment)) and [here](rust-lang/rust#87921 (comment)). It extends the list of saturating operations on integer types (like `saturating_add`, `saturating_sub`, `saturating_mul`, ...) by the function `fn saturating_div(self, rhs: Self) -> Self`. The stabilization of the feature `saturating_int_impl` (for the `Saturating` type) needs to have this stabilized first. Closes #89381
Give better error for `macro_rules name` follow up to #89221 r? ``@estebank`` ``@rustbot`` modify labels: +A-diagnostics +A-parser
Stabilise unix_process_wait_more, extra ExitStatusExt methods This stabilises the feature `unix_process_wait_more`. Tracking issue #80695, FCP needed. This was implemented in #79982 and merged in January.
This commit adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments. Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue #89653). LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e., -Clto).
Add LLVM CFI support to the Rust compiler This PR adds LLVM Control Flow Integrity (CFI) support to the Rust compiler. It initially provides forward-edge control flow protection for Rust-compiled code only by aggregating function pointers in groups identified by their number of arguments. Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by defining and using compatible type identifiers (see Type metadata in the design document in the tracking issue #89653). LLVM CFI can be enabled with -Zsanitizer=cfi and requires LTO (i.e., -Clto). Thank you, `@eddyb` and `@pcc,` for all the help!
|
I think you messed up the git subtree command. It seems like you are now pulling in the whole rust repo. |
|
That looks similar to what I did. |
|
What is the exact command you used? |
Now I'm stracing which does not seem ok. |
|
You could try deleting I pushed it to https://github.com/bjorn3/rustc_codegen_gcc/tree/sync_from_rust if you want to use that instead. |
|
I'd like to understand how to do it right for the future ;) . I was able to reproduce the same as this PR (i.e. with all the useless commits), so I'm not sure what I'm doing wrong. #!/bin/bash
git clone https://github.com/rust-lang/rust
git clone https://github.com/rust-lang/rustc_codegen_gcc
cd rust
git subtree push -P compiler/rustc_codegen_gcc/ ../rustc_codegen_gcc/ sync_from_rust? |
|
Yeah, pretty much. Which git version do you have? I used a self-built version of gitgitgadget/git#493 (commit gitgitgadget/git@19db9cf). I think you are hitting
which that PR fixes. |
|
That was it! |
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.