bors [Tue, 16 Nov 2021 02:23:42 +0000 (02:23 +0000)]
Auto merge of #90934 - JohnTitor:rollup-5soqo0j, r=JohnTitor
Rollup of 10 pull requests
Successful merges:
- #85766 (Stabilize File::options())
- #88601 (Implement `Termination` for `Result<Infallible, E>`)
- #90058 (Stabilize -Z strip as -C strip)
- #90790 (Fix standard library test with read_link)
- #90834 (Android is not GNU)
- #90835 (Rename WASI's `is_character_device` to `is_char_device`.)
- #90837 (Move some tests to more reasonable directories - 9)
- #90848 (Remove bigint_helper_methods for *signed* types)
- #90892 (fix ICE on Miri/CTFE copy of half a pointer)
- #90909 (disable portable SIMD tests in Miri)
Failed merges:
- #90128 (Stabilize -Z symbol-mangling-version=v0 as -C symbol-mangling-version=v0)
Yuki Okushi [Tue, 16 Nov 2021 00:14:21 +0000 (09:14 +0900)]
Rollup merge of #90848 - scottmcm:remove-signed-bigint-helpers, r=joshtriplett
Remove bigint_helper_methods for *signed* types
This PR inspired by `@cuviper's` comment @ https://github.com/rust-lang/rust/issues/90541#issuecomment-967309808
These are working well for *unsigned* types, so keep those, but for the the *signed* ones there are a bunch of questions about what the semantics and API should be. For the main "helpers for big integer implementations" use, there's no need for the signed versions anyway. There are plenty of other methods which exist for unsigned types but not signed ones, like `next_power_of_two`, so this isn't unusual.
Yuki Okushi [Tue, 16 Nov 2021 00:14:18 +0000 (09:14 +0900)]
Rollup merge of #90834 - cuviper:android-gnu, r=petrochenkov
Android is not GNU
For a long time, the Android targets had `target_env=""`, but this changed to `"gnu"` in Rust 1.49.0. I tracked this down to #77729 which started setting `"gnu"` in the `linux_base` target options, and this was inherited by `android_base`. Then #78929 split the env into `linux_gnu_base`, but `android_base` was also changed to follow that. Android was not specifically mentioned in either pull request, so I believe this was an accident. Moving it back to `linux_base` will use an empty `env` again.
r? ````@Mark-Simulacrum````
cc ````@petrochenkov````
bors [Mon, 15 Nov 2021 23:27:59 +0000 (23:27 +0000)]
Auto merge of #90827 - matthewjasper:assoc-item-cleanup-2, r=cjgillot
Assoc item cleanup Part 2
- Remove `AssocItem` from `RegionVariableOrigin::AutoRef`
- Use the `associated_item_def_ids` query instead of the `associated_items` query when possible
The change to `ObligationCauseCode` from #90639 is omitted because it caused a perf regression.
bors [Mon, 15 Nov 2021 20:19:23 +0000 (20:19 +0000)]
Auto merge of #90821 - scottmcm:new-slice-reverse, r=Mark-Simulacrum
MIRI says `reverse` is UB, so replace it with something LLVM can vectorize
For small types with padding, the current implementation is UB because it does integer operations on uninit values.
```
error: Undefined Behavior: using uninitialized data, but this operation requires initialized memory
--> /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/mod.rs:836:5
|
836 | / uint_impl! { u32, u32, i32, 32, 4294967295, 8, "0x10000b3", "0xb301", "0x12345678",
837 | | "0x78563412", "0x1e6a2c48", "[0x78, 0x56, 0x34, 0x12]", "[0x12, 0x34, 0x56, 0x78]", "", "" }
| |________________________________________________________________________________________________^ using uninitialized data, but this operation requires initialized memory
|
= help: this indicates a bug in the program: it performed an invalid operation, and caused Undefined Behavior
= help: see https://doc.rust-lang.org/nightly/reference/behavior-considered-undefined.html for further information
= note: inside `core::num::<impl u32>::rotate_left` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/num/uint_macros.rs:211:13
= note: inside `core::slice::<impl [Foo]>::reverse` at /playground/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/library/core/src/slice/mod.rs:701:58
```
<https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=340739f22ca5b457e1da6f361768edc6>
But LLVM has gotten smarter since I wrote the previous implementation in 2017, so this PR removes all the manual magic and just writes it in such a way that LLVM will vectorize. This code is much simpler and has very little `unsafe`, and is actually faster to boot!
If you're curious to see the codegen: <https://rust.godbolt.org/z/Pcn13Y9E3>
- We don't support capturing arguments from a non-literal format string like `format_args!(concat!(...))`. We could add that in a future enhancement, or we can decide that it isn't supported (as suggested in https://github.com/rust-lang/rust/issues/67984#issuecomment-801394736 ).
- I've updated the documentation.
- `panic!` now supports capture as well.
- There are potentially opportunities to further improve diagnostics for invalid usage, such as if it looks like the user tried to use an expression rather than a variable. However, such cases are all already caught and provide reasonable syntax errors now, and we can always provided even friendlier diagnostics in the future.
bors [Mon, 15 Nov 2021 11:18:44 +0000 (11:18 +0000)]
Auto merge of #90717 - kit-981:fix-ld64-flags, r=petrochenkov
Fix ld64 flags
- The `-exported_symbols_list` argument appears to be malformed for `ld64` (if you are not going through `clang`).
- The `-dynamiclib` argument isn't support for `ld64`. It should be guarded behind a compiler flag.
These problems are fixed by these changes. I have also refactored the way linker arguments are generated to be ld/compiler agnostic and therefore less error prone.
These changes are necessary to support cross-compilation to darwin targets.
Josh Triplett [Thu, 21 Oct 2021 11:19:46 +0000 (13:19 +0200)]
Stabilize -Z strip as -C strip
Leave -Z strip available temporarily as an alias, to avoid breaking
cargo until cargo transitions to using -C strip. (If the user passes
both, the -C version wins.)
bors [Mon, 15 Nov 2021 03:19:01 +0000 (03:19 +0000)]
Auto merge of #90684 - jyn514:dist-aliases, r=Mark-Simulacrum
Change paths for `dist` command to match the components they generate
Before, you could have the confusing situation where the command to
generate a component had no relation to the name of that component (e.g.
the `rustc` component was generated with `src/librustc`). This changes
the name to make them match up.
bors [Sun, 14 Nov 2021 18:47:42 +0000 (18:47 +0000)]
Auto merge of #88282 - Neutron3529:patch-4, r=Mark-Simulacrum
Optimize BinaryHeap::extend from Vec
This improves the performance of extending `BinaryHeap`s from vectors directly. Future work may involve extending this optimization to other, similar, cases where the length of the added elements is well-known, but this is not yet done in this PR.
kit [Mon, 8 Nov 2021 23:36:47 +0000 (10:36 +1100)]
Refactor linker argument generation
This commit refactors linker argument generation to leverage a helper
function that abstracts away details governing how these arguments are
transformed and provided to the linker.
This fixes the misuse of the `-exported_symbols_list` when an ld-like
linker is used rather than a compiler. A compiler would expect
`-Wl,-exported_symbols_list,path` but ld would expect
`-exported_symbols_list` and `path` as two seperate arguments. Prior
to this change, an ld-like linker was given
`-exported_symbols_list,path`.
kit [Mon, 8 Nov 2021 09:45:04 +0000 (20:45 +1100)]
Add a helper method for linker arguments
Linker arguments must transformed when Rust is interacting with the
linker through a compiler. This commit introduces a helper function
that abstracts away details of this transformation.
bors [Sun, 14 Nov 2021 01:06:05 +0000 (01:06 +0000)]
Auto merge of #90883 - matthiaskrgr:rollup-iu9k5pe, r=matthiaskrgr
Rollup of 3 pull requests
Successful merges:
- #90771 (Fix trait object error code)
- #90840 (relate lifetime in `TypeOutlives` bounds on drop impls)
- #90853 (rustdoc: Use an empty Vec instead of Option<Vec>)
bors [Sat, 13 Nov 2021 17:10:15 +0000 (17:10 +0000)]
Auto merge of #89551 - jhpratt:stabilize-const_raw_ptr_deref, r=oli-obk
Stabilize `const_raw_ptr_deref` for `*const T`
This stabilizes dereferencing immutable raw pointers in const contexts.
It does not stabilize `*mut T` dereferencing. This is behind the
same feature gate as mutable references.
Since it is unstable, doc-hidden and has no associated tracking issue it was never meant for public use. And since
it is no longer used outside alloc itself it can be made private again.
Also remove some functions that are dead due to lack of internal users.
Joshua Nelson [Mon, 8 Nov 2021 04:37:28 +0000 (04:37 +0000)]
Change paths for `dist` command to match the components they generate
Before, you could have the confusing situation where the command to
generate a component had no relation to the name of that component (e.g.
the `rustc` component was generated with `src/librustc`). This changes
the name to make them match up.
bors [Sat, 13 Nov 2021 08:22:52 +0000 (08:22 +0000)]
Auto merge of #87264 - mystor:expand_literal, r=petrochenkov
proc_macro: Add an expand_expr method to TokenStream
This feature is aimed at giving proc macros access to powers similar to those used by builtin macros such as `format_args!` or `concat!`. These macros are able to accept macros in place of string literal parameters, such as the format string, as they perform recursive macro expansion while being expanded.
This can be especially useful in many cases thanks to helper macros like `concat!`, `stringify!` and `include_str!` which are often used to construct string literals at compile-time in user code.
For now, this method only allows expanding macros which produce literals, although more expressions will be supported before the method is stabilized.
In earlier versions of this PR, this method exclusively returned `Literal`, and spans on returned literals were stripped of expansion context before being returned to be as conservative as possible about permission leakage. The method's naming has been generalized to eventually support arbitrary expressions, and the context stripping has been removed (https://github.com/rust-lang/rust/pull/87264#discussion_r674863279), which should allow for more general APIs like "format_args_implicits" (https://github.com/rust-lang/rust/issues/67984) to be supported as well.
bors [Sat, 13 Nov 2021 05:19:39 +0000 (05:19 +0000)]
Auto merge of #90041 - jfrimmel:rt_copy_checks, r=Mark-Simulacrum
Re-enable `copy[_nonoverlapping]()` debug-checks
This commit re-enables the debug checks for valid usages of the two functions `copy()` and `copy_nonoverlapping()`. Those checks were commented out in #79684 in order to make the functions const. All that's been left was a FIXME, that could not be resolved until there is was way to only do the checks at runtime.
Since #89247 there is such a way: `const_eval_select()`. This commit uses that new intrinsic in order to either do nothing (at compile time) or to do the old checks (at runtime).
The change itself is rather small: in order to make the checks usable with `const_eval_select`, they are moved into a local function (one for `copy` and one for `copy_nonoverlapping` to keep symmetry).
The change does not break referential transparency, as there is nothing you can do at compile time, which you cannot do on runtime without getting undefined behavior. The CTFE-engine won't allow missuses. The other way round is also fine.
I've refactored the code to use `#[cfg(debug_assertions)]` on the new items. If that is not desired, the second commit can be dropped.
I haven't added any checks, as I currently don't know, how to test this properly.
Closes #90012.
cc `@rust-lang/lang,` `@rust-lang/libs` and `@rust-lang/wg-const-eval` (as those teams are linked in the issue above).
bors [Sat, 13 Nov 2021 02:17:20 +0000 (02:17 +0000)]
Auto merge of #89167 - workingjubilee:use-simd, r=MarkSimulacrum
pub use core::simd;
A portable abstraction over SIMD has been a major pursuit in recent years for several programming languages. In Rust, `std::arch` offers explicit SIMD acceleration via compiler intrinsics, but it does so at the cost of having to individually maintain each and every single such API, and is almost completely `unsafe` to use. `core::simd` offers safe abstractions that are resolved to the appropriate SIMD instructions by LLVM during compilation, including scalar instructions if that is all that is available.
`core::simd` is enabled by the `#![portable_simd]` nightly feature tracked in https://github.com/rust-lang/rust/issues/86656 and is introduced here by pulling in the https://github.com/rust-lang/portable-simd repository as a subtree. We built the repository out-of-tree to allow faster compilation and a stochastic test suite backed by the proptest crate to verify that different targets, features, and optimizations produce the same result, so that using this library does not introduce any surprises. As these tests are technically non-deterministic, and thus can introduce overly interesting Heisenbugs if included in the rustc CI, they are visible in the commit history of the subtree but do nothing here. Some tests **are** introduced via the documentation, but these use deterministic asserts.
There are multiple unsolved problems with the library at the current moment, including a want for better documentation, technical issues with LLVM scalarizing and lowering to libm, room for improvement for the APIs, and so far I have not added the necessary plumbing for allowing the more experimental or libm-dependent APIs to be used. However, I thought it would be prudent to open this for review in its current condition, as it is both usable and it is likely I am going to learn something else needs to be fixed when bors tries this out.
The major types are
- `core::simd::Simd<T, N>`
- `core::simd::Mask<T, N>`
There is also the `LaneCount` struct, which, together with the SimdElement and SupportedLaneCount traits, limit the implementation's maximum support to vectors we know will actually compile and provide supporting logic for bitmasks. I'm hoping to simplify at least some of these out of the way as the compiler and library evolve.
Scott McMurray [Sat, 13 Nov 2021 01:00:47 +0000 (17:00 -0800)]
Remove bigint_helper_methods for *signed* types
These are working well for *unsigned* types, for the the signed ones there are a bunch of questions about what the semantics and API should be. And for the main "helpers for big integer implementations" use, there's no need for the signed versions anyway.
And there are plenty of other methods which exist for unsigned types but not signed ones, like `next_power_of_two`, so this isn't unusual.
Jubilee Young [Fri, 22 Oct 2021 07:47:12 +0000 (00:47 -0700)]
Test core::simd works
These tests just verify some basic APIs of core::simd function, and
guarantees that attempting to access the wrong things doesn't work.
The majority of tests are stochastic, and so remain upstream, but
a few deterministic tests arrive in the subtree as doc tests.
Jubilee Young [Fri, 22 Oct 2021 07:12:00 +0000 (00:12 -0700)]
Expose portable-simd as core::simd
This enables programmers to use a safe alternative to the current
`extern "platform-intrinsics"` API for writing portable SIMD code.
This is `#![feature(portable_simd)]` as tracked in #86656
proc_macro: Add an expand_expr method to TokenStream
This feature is aimed at giving proc macros access to powers similar to
those used by builtin macros such as `format_args!` or `concat!`. These
macros are able to accept macros in place of string literal parameters,
such as the format string, as they perform recursive macro expansion
while being expanded.
This can be especially useful in many cases thanks to helper macros like
`concat!`, `stringify!` and `include_str!` which are often used to
construct string literals at compile-time in user code.
For now, this method only allows expanding macros which produce
literals, although more expresisons will be supported before the method
is stabilized.
bors [Fri, 12 Nov 2021 19:28:04 +0000 (19:28 +0000)]
Auto merge of #90836 - matthiaskrgr:rollup-ou6yrlw, r=matthiaskrgr
Rollup of 7 pull requests
Successful merges:
- #90589 (rustc_llvm: update PassWrapper for recent LLVM)
- #90644 (Extend the const swap feature)
- #90704 (Unix ExitStatus comments and a tiny docs fix)
- #90761 (Shorten Span of unused macro lints)
- #90795 (Add more comments to explain the code to generate the search index)
- #90798 (Document `unreachable!` custom panic message)
- #90826 (rustc_feature: Convert `BuiltinAttribute` from tuple to a struct)
Matthias Krüger [Fri, 12 Nov 2021 18:17:33 +0000 (19:17 +0100)]
Rollup merge of #90798 - edmorley:doc-unreachable-custom-message, r=dtolnay
Document `unreachable!` custom panic message
The `unreachable!` docs previously did not mention that there was a second form, `unreachable!("message")` that could be used to specify a custom panic message,
The docs now mention this feature in the same wording as currently used for `unimplemented!`:
https://doc.rust-lang.org/core/macro.unimplemented.html#panics
Matthias Krüger [Fri, 12 Nov 2021 18:17:32 +0000 (19:17 +0100)]
Rollup merge of #90795 - GuillaumeGomez:more-search-index-comments, r=notriddle
Add more comments to explain the code to generate the search index
Fixes #90766.
I tried to put comments when the code wasn't easy to understand at first sight and added more documentation on the recursive function. Please tell me if I misused the terminology or if comments can be improved or added into other places.
Guillaume Gomez [Fri, 12 Nov 2021 14:25:13 +0000 (15:25 +0100)]
Remove unneeded FIXME: after testing the suggested changes, we reached the conclusion that the code readibility wasn't worth the almost unnoticeable perf improvement
Scott McMurray [Fri, 12 Nov 2021 04:32:18 +0000 (20:32 -0800)]
MIRI says `reverse` is UB, so replace it with an implementation that LLVM can vectorize
For small types with padding, the current implementation is UB because it does integer operations on uninit values. But LLVM has gotten smarter since I wrote the previous implementation in 2017, so remove all the manual magic and just write it in such a way that LLVM will vectorize. This code is much simpler (albeit nuanced) and has very little `unsafe`, and is actually faster to boot!
bors [Thu, 11 Nov 2021 22:00:53 +0000 (22:00 +0000)]
Auto merge of #90489 - jyn514:load-all-extern-crates, r=petrochenkov
rustdoc: Go back to loading all external crates unconditionally
This *continues* to cause regressions. This code will be unnecessary
once access to the resolver happens fully before creating the tyctxt
(#83761), so load all crates unconditionally for now. To minimize churn, this leaves in the code for loading crates selectively.
Ian Jackson [Mon, 8 Nov 2021 17:28:02 +0000 (17:28 +0000)]
unix::ExitStatusExt: Correct reference to _exit system call
As discussed here
https://github.com/rust-lang/rust/pull/88300#issuecomment-936085371
exit is (conventionally) a library function, with _exit being the
actual system call.
I have checked the other references and they say "if the process
terminated by calling `exti`". I think despite the slight
imprecision (strictly, it should read iff ... `_exit`), this is
clearer. Anyone who knows about the distinction between `exit` and
`_exit` will not be confused.
`_exit` is the correct traditional name for the system call, despite
Linux calling it `exit_group` or `exit`:
https://www.freebsd.org/cgi/man.cgi?query=_exit&sektion=2&n=1
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
Ed Morley [Thu, 11 Nov 2021 13:41:21 +0000 (13:41 +0000)]
Document `unreachable!()` custom panic message
The `unreachable!` docs previously did not mention that there was a second
form, `unreachable!("message")` that could be used to specify a custom panic
message,
The docs now mention this in the same style as currently used for `unimplemented!`:
https://doc.rust-lang.org/core/macro.unimplemented.html#panics
bors [Thu, 11 Nov 2021 12:07:53 +0000 (12:07 +0000)]
Auto merge of #88798 - sunfishcode:sunfishcode/windows-null-handles, r=joshtriplett
Fix assertion failures in `OwnedHandle` with `windows_subsystem`.
As discussed in #88576, raw handle values in Windows can be null, such
as in `windows_subsystem` mode, or when consoles are detached from a
process. So, don't use `NonNull` to hold them, don't assert that they're
not null, and remove `OwnedHandle`'s `repr(transparent)`. Introduce a
new `HandleOrNull` type, similar to `HandleOrInvalid`, to cover the FFI
use case.
bors [Thu, 11 Nov 2021 09:13:22 +0000 (09:13 +0000)]
Auto merge of #90755 - scottmcm:spec-array-clone, r=jackh726
Specialize array cloning for Copy types
Because after PR 86041, the optimizer no longer load-merges at the LLVM IR level, which might be part of the perf loss. (I'll run perf and see if this makes a difference.)
Also I added a codegen test so this hopefully won't regress in future -- it passes on stable and with my change here, but not on the 2021-11-09 nightly.
Example on current nightly: <https://play.rust-lang.org/?version=nightly&mode=release&edition=2021&gist=1f52d46fb8fc3ca3ac9f097390085ffa>
```rust
type T = u8;
const N: usize = 3;
bors [Thu, 11 Nov 2021 02:52:32 +0000 (02:52 +0000)]
Auto merge of #83846 - torhovland:issue-10971, r=davidtwco
Added the --temps-dir option
Fixes #10971.
The new `--temps-dir` option puts intermediate files in a user-specified directory. This provides a fix for the issue where parallel invocations of rustc would overwrite each other's intermediate files.
No files are kept in the intermediate directory unless `-C save-temps=yes`.
If additional files are specifically requested using `--emit asm,llvm-bc,llvm-ir,obj,metadata,link,dep-info,mir`, these will be put in the output directory rather than the intermediate directory.
This is a backward-compatible change, i.e. if `--temps-dir` is not specified, the behavior is the same as before.