Dylan DPC [Wed, 23 Mar 2022 02:05:28 +0000 (03:05 +0100)]
Rollup merge of #91608 - workingjubilee:fold-neon-fp, r=nagisa,Amanieu
Fold aarch64 feature +fp into +neon
Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64:
The Neon unit, which handles both floating point and SIMD instructions.
Moreover, a configuration for AArch64 must include both or neither.
Arm says "entirely proprietary" toolchains may omit floating point:
https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point
In the Programmer's Guide for Armv8-A, Arm says AArch64 can have
both FP and Neon or neither in custom implementations:
https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON
In "Bare metal boot code for Armv8-A", enabling Neon and FP
is just disabling the same trap flag:
https://developer.arm.com/documentation/dai0527/a
In an unlikely future where "Neon and FP" become unrelated,
we can add "[+-]fp" as its own feature flag.
Until then, we can simplify programming with Rust on AArch64 by
folding both into "[+-]neon", which is valid as it supersets both.
"[+-]neon" is retained for niche uses such as firmware, kernels,
"I just hate floats", and so on.
I am... pretty sure no one is relying on this.
An argument could be made that, as we are not an "entirely proprietary" toolchain, we should not support AArch64 without floats at all. I think that's a bit excessive. However, I want to recognize the intent: programming for AArch64 should be simplified where possible. For x86-64, programmers regularly set up illegal feature configurations because it's hard to understand them, see https://github.com/rust-lang/rust/issues/89586. And per the above notes, plus the discussion in https://github.com/rust-lang/rust/issues/86941, there should be no real use cases for leaving these features split: the two should in fact always go together.
Jubilee Young [Sat, 4 Dec 2021 01:56:59 +0000 (17:56 -0800)]
Fold aarch64 feature +fp into +neon
Arm's FEAT_FP and Feat_AdvSIMD describe the same thing on AArch64:
The Neon unit, which handles both floating point and SIMD instructions.
Moreover, a configuration for AArch64 must include both or neither.
Arm says "entirely proprietary" toolchains may omit floating point:
https://developer.arm.com/documentation/102374/0101/Data-processing---floating-point
In the Programmer's Guide for Armv8-A, Arm says AArch64 can have
both FP and Neon or neither in custom implementations:
https://developer.arm.com/documentation/den0024/a/AArch64-Floating-point-and-NEON
In "Bare metal boot code for Armv8-A", enabling Neon and FP
is just disabling the same trap flag:
https://developer.arm.com/documentation/dai0527/a
In an unlikely future where "Neon and FP" become unrelated,
we can add "[+-]fp" as its own feature flag.
Until then, we can simplify programming with Rust on AArch64 by
folding both into "[+-]neon", which is valid as it supersets both.
"[+-]neon" is retained for niche uses such as firmware, kernels,
"I just hate floats", and so on.
As its name suggests, `TokenTreeOrTokenTreeSlice` is either a single
`TokenTree` or a slice of them. It has methods `len` and `get_tt` that
let it be treated much like an ordinary slice. The reason it isn't an
ordinary slice is that for `TokenTree::Delimited` the open and close
delimiters are represented implicitly, and when they are needed they are
constructed on the fly with `Delimited::{open,close}_tt`, rather than
being present in memory.
This commit changes `Delimited` so the open and close delimiters are
represented explicitly. As a result, `TokenTreeOrTokenTreeSlice` is no
longer needed and `MatcherPos` and `MatcherTtFrame` can just use an
ordinary slice. `TokenTree::{len,get_tt}` are also removed, because they
were only needed to support `TokenTreeOrTokenTreeSlice`.
The change makes the code shorter and a little bit faster on benchmarks
that use macro expansion heavily, partly because `MatcherPos` is a lot
smaller (less data to `memcpy`) and partly because ordinary slice
operations are faster than `TokenTreeOrTokenTreeSlice::{len,get_tt}`.
bors [Tue, 22 Mar 2022 16:24:50 +0000 (16:24 +0000)]
Auto merge of #94693 - nnethercote:parser-inlining, r=petrochenkov
Inline some parser functions
Some crates that do a lot of complex declarative macro expansion spend a lot of time parsing (and reparsing) tokens. These commits inline some functions for some minor speed wins.
bors [Tue, 22 Mar 2022 05:48:49 +0000 (05:48 +0000)]
Auto merge of #95158 - sunfishcode:sunfishcode/windows-8, r=joshtriplett
Preserve the Windows `GetLastError` error in `HandleOrInvalid`.
In the `TryFrom<HandleOrInvalid> for OwnedHandle` and
`TryFrom<HandleOrNull> for OwnedHandle` implemenations, `forget` the
owned handle on the error path, to avoid calling `CloseHandle` on an
invalid handle. It's harmless, except that it may overwrite the
thread's `GetLastError` error.
bors [Mon, 21 Mar 2022 19:23:00 +0000 (19:23 +0000)]
Auto merge of #95180 - matthiaskrgr:rollup-ai1ch2s, r=matthiaskrgr
Rollup of 6 pull requests
Successful merges:
- #95074 (Refactor: use `format-args-capture` and remove unnecessary nested if blocks in some parts of `rust_passes`)
- #95085 (Return err instead of ICE)
- #95116 (Add needs-* directives to many tests)
- #95129 (Remove animation on source sidebar)
- #95166 (Update the unstable book with the new `values()` form of check-cfg)
- #95175 (move `adt_const_params` to its own tracking issue)
Matthias Krüger [Mon, 21 Mar 2022 18:48:31 +0000 (19:48 +0100)]
Rollup merge of #95085 - ouz-a:master5, r=jackh726
Return err instead of ICE
Having `escaping_bound_vars` results in ICE when trying to create `ty::Binder::dummy`, to avoid it we return err like the line above. I think this requires a more sophisticated fix, I would love to investigate if mentorship is available 🤓
bors [Mon, 21 Mar 2022 15:17:08 +0000 (15:17 +0000)]
Auto merge of #95169 - Smittyvb:union-test-ub, r=bjorn3
Don't run UB in test suite
This splits `ui/unsafe/union.rs` to make it so only the non-UB parts are run. It also means we can do more testing of the location of error messages (which are a bit different with the THIR unsafety checker). `union-modification.rs` has no UB (according to Miri), and `union.rs` has errors (but would have UB if not for those errors).
By putting them in `TtParser`, we can reuse them for every rule in a
macro. With that done, they can be `SmallVec` instead of `Vec`, and this
is a performance win because these vectors are hot and `SmallVec`
operations are a bit slower due to always needing an "inline or heap?"
check.
This type was a small performance win for `html5ever`, which uses a
macro with hundreds of very simple rules that don't contain any
metavariables. But this type is complicated (extra lifetimes) and
perf-neutral for macros that do have metavariables.
This commit removes `MatcherPosHandle`, simplifying things a lot. This
increases the allocation rate for `html5ever` and similar cases a bit,
but makes things easier for follow-up changes that will improve
performance more than what we lost here.
Dan Gohman [Sun, 20 Mar 2022 22:37:31 +0000 (15:37 -0700)]
Preserve the Windows `GetLastError` error in `HandleOrInvalid`.
In the `TryFrom<HandleOrInvalid> for OwnedHandle` and
`TryFrom<HandleOrNull> for OwnedHandle` implemenations, `forget` the
owned handle on the error path, to avoid calling `CloseHandle` on an
invalid handle. It's harmless, except that it may overwrite the
thread's `GetLastError` error.
bors [Sun, 20 Mar 2022 21:36:57 +0000 (21:36 +0000)]
Auto merge of #95148 - matthiaskrgr:rollup-jsb1ld9, r=matthiaskrgr
Rollup of 4 pull requests
Successful merges:
- #95114 (Skip a test if symlink creation is not possible)
- #95131 (Fix docs for default rmeta filename.)
- #95135 (Fix a not emitted unmatched angle bracket error)
- #95145 (Fix typo interator->iterator)
Matthias Krüger [Sun, 20 Mar 2022 19:42:44 +0000 (20:42 +0100)]
Rollup merge of #95131 - ehuss:fix-metadata-filename, r=bjorn3
Fix docs for default rmeta filename.
The docs for the default filename for `--emit=metadata` was wrong, it was missing the `lib` prefix. The current implementation for that default is [here](https://github.com/rust-lang/rust/blob/f2661cfe341f88bea919daf52a07015dceaf7a6a/compiler/rustc_session/src/output.rs#L140). Perhaps somewhat confusing, but `lib` is used for all crate types.
cc https://github.com/rust-lang/rust/issues/68839#issuecomment-1073118716
Matthias Krüger [Sun, 20 Mar 2022 19:42:43 +0000 (20:42 +0100)]
Rollup merge of #95114 - ChrisDenton:symlink-test, r=the8472
Skip a test if symlink creation is not possible
If someone running tests on Windows does not have Developer Mode enabled then creating symlinks will fail which in turn would cause this test to fail. This can be a stumbling block for contributors.
bors [Sun, 20 Mar 2022 13:48:23 +0000 (13:48 +0000)]
Auto merge of #95071 - RalfJung:arbitrary-self-dyn, r=oli-obk
Miri: implement arbitrary-self dyn receivers
Roughly follows the [codegen logic](https://github.com/rust-lang/rust/blob/851fcc7a54262748b1aa9e16de91453998d896f3/compiler/rustc_codegen_ssa/src/mir/block.rs#L809).
Fixes https://github.com/rust-lang/miri/issues/1038
r? `@oli-obk` Cc `@eddyb`
bors [Sun, 20 Mar 2022 11:20:26 +0000 (11:20 +0000)]
Auto merge of #92962 - frank-king:btree_entry_no_insert, r=Amanieu
BTreeMap::entry: Avoid allocating if no insertion
This PR allows the `VacantEntry` to borrow from an empty tree with no root, and to lazily allocate a new root node when the user calls `.insert(value)`.
bors [Sun, 20 Mar 2022 08:35:40 +0000 (08:35 +0000)]
Auto merge of #95133 - matthiaskrgr:rollup-4q0u804, r=matthiaskrgr
Rollup of 5 pull requests
Successful merges:
- #94749 (remove_dir_all: use fallback implementation on Miri)
- #94948 (Fix diagnostics for `#![feature(deprecated_suggestion)]`)
- #94989 (Add Stream alias for AsyncIterator)
- #95108 (Give more details in `Display` for `hir::Target`)
- #95110 (Provide more useful documentation of conversion methods)
Matthias Krüger [Sun, 20 Mar 2022 08:15:01 +0000 (09:15 +0100)]
Rollup merge of #95110 - wmstack:patch-1, r=Dylan-DPC
Provide more useful documentation of conversion methods
I thought that the documentation for these methods needed to be a bit more explanatory for new users. For advanced users, the comments are relatively unnecessary. I think it would be useful to explain precisely what the method does. As a new user, when you see the `into` method, where the type is inferred, if you are new you don't even know what you convert to, because it is implicit. I believe this can help new users understand.
Matthias Krüger [Sun, 20 Mar 2022 08:15:00 +0000 (09:15 +0100)]
Rollup merge of #95108 - scottmcm:more-in-target-display, r=Dylan-DPC
Give more details in `Display` for `hir::Target`
Made because I was making a code change and got a very confusing "should be applied to a method, not a method" error.
```
error[E0718]: `into_try_type` language item must be applied to a method
--> library\core\src\ops\try_trait.rs:352:32
|
352 | #[cfg_attr(not(bootstrap), lang = "into_try_type")]
| ^^^^^^^^^^^^^^^^^^^^^^ attribute should be applied to a method, not a method
```
With this change the error is more actionable
```
error[E0718]: `into_try_type` language item must be applied to a required trait method
--> library\core\src\ops\try_trait.rs:352:32
|
352 | #[cfg_attr(not(bootstrap), lang = "into_try_type")]
| ^^^^^^^^^^^^^^^^^^^^^^ attribute should be applied to a required trait method, not a provided trait method
```
The new implementation requires `openat`, `unlinkat`, and `fdopendir`. These cannot easily be shimmed in Miri since libstd does not expose APIs corresponding to them. So for now it is probably easiest to just use the fallback code in Miri. Nobody should run Miri as root anyway...
bors [Sun, 20 Mar 2022 04:31:23 +0000 (04:31 +0000)]
Auto merge of #95063 - tromey:fix-94458-gdb-char, r=Mark-Simulacrum
Fix debuginfo tests with GDB 11.2
GDB 11.2 added support for DW_ATE_UTF, which caused some test
failures. This fixes these tests by changing the format that is used,
and adds a new test to verify that characters are emitted as something
that GDB can print in a char-like way.
bors [Sun, 20 Mar 2022 01:50:36 +0000 (01:50 +0000)]
Auto merge of #94976 - jclulow:solaris-festival, r=Mark-Simulacrum
solaris build environment should include libsendfile/liblgrp
As of version 0.2.120 of the libc crate, the solaris target now requires
some additional libraries to be present in the sysroot. Note that the
solaris target doesn't really build against files from Solaris, but
rather against some files from DilOS (a platform similar to both Solaris
and illumos). Pull in the extra libraries and their compilation links
from that apt repository.
bors [Sat, 19 Mar 2022 19:41:10 +0000 (19:41 +0000)]
Auto merge of #95103 - ehuss:update-cargo, r=ehuss
Update cargo
9 commits in 65c82664263feddc5fe2d424be0993c28d46377a..109bfbd055325ef87a6e7f63d67da7e838f8300b
2022-03-09 02:32:56 +0000 to 2022-03-17 21:43:09 +0000
- Refactor RegistryData::load to handle management of the index cache (rust-lang/cargo#10482)
- Separate VCS command paths with "--" (rust-lang/cargo#10483)
- Fix panic when artifact target is used for `[target.'cfg(<target>)'.dependencies` (rust-lang/cargo#10433)
- Bump git2@0.14.2 and libgit2-sys@0.13.2 (rust-lang/cargo#10479)
- vendor: Don't allow multiple values for --sync (rust-lang/cargo#10448)
- Use types to make clere (credential process || token) (rust-lang/cargo#10471)
- Warning on conflicting keys (rust-lang/cargo#10316)
- Registry functions return Poll to enable parallel fetching of index data (rust-lang/cargo#10064)
- Refine the contributor guide (rust-lang/cargo#10468)
Dylan DPC [Sat, 19 Mar 2022 13:50:27 +0000 (14:50 +0100)]
Rollup merge of #95109 - Urgau:check-cfg-all-any, r=petrochenkov
Extend --check-cfg tests to all predicate inside all/any
Now that https://github.com/rust-lang/rust/pull/94295 is merged it's time to add more tests to check that all predicate inside `all` and `any` are always checked.
Dylan DPC [Sat, 19 Mar 2022 13:50:26 +0000 (14:50 +0100)]
Rollup merge of #95072 - tromey:parallel-debug-tests, r=tmiasko
Re-enable parallel debuginfo tests
Debuginfo tests are serialized due to some older version of LLDB.
However, that comment was last touched in 2014, so presumably these
older versions are long since obsolete.
Add a `process_group` method to `std::os::unix::process::CommandExt` that
allows setting the process group id (i.e. calling `setpgid`) in the child, thus
enabling users to set process groups while leveraging the `posix_spawn` fast
path.
Scott McMurray [Sat, 19 Mar 2022 09:03:37 +0000 (02:03 -0700)]
Give more details in `Display` for `hir::Target`
Made because I was making a code change and got a very confusing "should be applied to a method, not a method" error.
```
error[E0718]: `into_try_type` language item must be applied to a method
--> library\core\src\ops\try_trait.rs:352:32
|
352 | #[cfg_attr(not(bootstrap), lang = "into_try_type")]
| ^^^^^^^^^^^^^^^^^^^^^^ attribute should be applied to a method, not a method
```
Waleed Dahshan [Sat, 19 Mar 2022 07:52:30 +0000 (18:52 +1100)]
Provide more useful documentation of conversion methods
I thought that the documentation for these methods needed to be a bit more explanatory for new users. For advanced users, the comments are relatively unnecessary. I think it would be useful to explain precisely what the method does. As a new user, when you see the `into` method, where the type is inferred, if you are new you don't even know what you convert to, because it is implicit. I believe this can help new users understand.
bors [Sat, 19 Mar 2022 02:16:00 +0000 (02:16 +0000)]
Auto merge of #95101 - Dylan-DPC:rollup-r1f1v9t, r=Dylan-DPC
Rollup of 6 pull requests
Successful merges:
- #92519 (Use verbatim paths for `process::Command` if necessary)
- #92612 (Update stdlib for the l4re target)
- #92663 (Implement `Write for Cursor<[u8; N]>`, plus `A: Allocator` cursor support)
- #93263 (Consistently present absent stdio handles on Windows as NULL handles.)
- #93692 (keyword_docs: document use of `in` with `pub` keyword)
- #94984 (add `CStr` method that accepts any slice containing a nul-terminated string)
Dylan DPC [Sat, 19 Mar 2022 01:02:02 +0000 (02:02 +0100)]
Rollup merge of #94984 - ericseppanen:cstr_from_bytes, r=Mark-Simulacrum
add `CStr` method that accepts any slice containing a nul-terminated string
I haven't created an issue (tracking or otherwise) for this yet; apologies if my approach isn't correct. This is my first code contribution.
This change adds a member fn that converts a slice into a `CStr`; it is intended to be safer than `from_ptr` (which is unsafe and may read out of bounds), and more useful than `from_bytes_with_nul` (which requires that the caller already know where the nul byte is).
The reason I find this useful is for situations like this:
```rust
let mut buffer = [0u8; 32];
unsafe {
some_c_function(buffer.as_mut_ptr(), buffer.len());
}
let result = CStr::from_bytes_with_nul(&buffer).unwrap();
```
This code above returns an error with `kind = InteriorNul`, because `from_bytes_with_nul` expects that the caller has passed in a slice with the NUL byte at the end of the slice. But if I just got back a nul-terminated string from some FFI function, I probably don't know where the NUL byte is.
I would wish for a `CStr` constructor with the following properties:
- Accept `&[u8]` as input
- Scan for the first NUL byte and return the `CStr` that spans the correct sub-slice (see [future note below](https://github.com/rust-lang/rust/pull/94984#issuecomment-1070754281)).
- Return an error if no NUL byte is found within the input slice
I asked on [Zulip](https://rust-lang.zulipchat.com/#narrow/stream/122651-general/topic/CStr.20from.20.26.5Bu8.5D.20without.20knowing.20the.20NUL.20location.3F) whether this sounded like a good idea, and got a couple of positive-sounding responses from ``@joshtriplett`` and ``@AzureMarker.``
This is my first draft, so feedback is welcome.
A few issues that definitely need feedback:
1. Naming. ``@joshtriplett`` called this `from_bytes_with_internal_nul` on Zulip, but after staring at all of the available methods, I believe that this function is probably what end users want (rather than the existing fn `from_bytes_with_nul`). Giving it a simpler name (**`from_bytes`**) implies that this should be their first choice.
2. Should I add a similar method on `CString` that accepts `Vec<u8>`? I'd assume the answer is probably yes, but I figured I'd try to get early feedback before making this change bigger.
3. What should the error type look like? I made a unit struct since `CStr::from_bytes` can only fail in one obvious way, but if I need to do this for `CString` as well then that one may want to return `FromVecWithNulError`. And maybe that should dictate the shape of the `CStr` error type also?
Also, cc ``@poliorcetics`` who wrote #73139 containing similar fns.