Rollup of 6 pull requests
Successful merges:
- #64060 (Improve hygiene of `alloc::format!`)
- #64072 (Replace file_stem by file_name in rustdoc markdown)
- #64129 (vxWorks: set DEFAULT_MIN_STACK_SIZE to 256K and use min_stack to pass initial stack size to rtpSpawn)
- #64188 (rustc: Allow the cdylib crate type with wasm32-wasi)
- #64326 (Fixed documentation within c_str::from_ptr)
- #64349 (documentation for AtomicPtr CAS operations)
Failed merges:
r? @ghost
documentation for AtomicPtr CAS operations
The examples in the documentation for AtomicPtr CAS operations only show code that does *not* perform the CAS operation. I suggest to change them so that they actually do exchange the AtomicPtr's value.
rustc: Allow the cdylib crate type with wasm32-wasi
The wasm32-wasi target respects configuration around `crt-static` in
general, but is defaulted to being static. This interacted badly with
code which validated the `cdylib` crate type for `wasm32-wasi`,
erroneously saying that the `cdylib` crate type wasn't supported on
`wasm32-wasi` by default. This commit sets the appropriate flag in
`wasm32_wasi`'s target specification to indicate that the `cdylib` crate
type is supported regardless of `crt-static`
Closes#64187
vxWorks: set DEFAULT_MIN_STACK_SIZE to 256K and use min_stack to pass initial stack size to rtpSpawn
vxWorks: set DEFAULT_MIN_STACK_SIZE to 256K and use min_stack to pass initial stack size to rtpSpawn
r? @alexcrichton
cc @n-salim
Replace file_stem by file_name in rustdoc markdown
Before this PR, a file name like `some.file.md` will be output to a file named `some.html` with is not correct because the expected output file must be `some.file.html`
This ensures that the failure cases for finding the codegen backend and
for finding the rustc binary are essentially the same, and since we
almost always will load the codegen backend, this is essentially meaning
that the rustc change is not a regression.
rustc_mir: buffer -Zdump-mir output instead of pestering the kernel constantly.
This brings `mir-opt` tests from `197s` (over 3 minutes!) to `2.85s`, on my build server.
That's a nice speedup of about `69x` and so it definitely fixes#58485, for me.
It's such a beginner mistake I feel like maybe `clippy` should lint against it?
(cc @Manishearth @oli-obk)
lldb: avoid mixing "Hit breakpoint" message with other output.
This is to get `src/test/debuginfo/lexical-scopes-in-block-expression.rs` working.
It used to work like a week ago, and the main change that happened was I switched from Python 2 to Python 3 (I don't remember why, but I did get rid of the build dir entirely, and it fixed something else).
The error was:
```
error: line not found in debugger output: [...]$27 = 10
```
Relevant part of the output:
```
print val
(long) $26 = 15
print ten
(long) $27 = 10 Hit breakpoint 15.1: where = a`lexical_scopes_in_block_expression::main::hcdd5c3caa9166e73 + 1223 at lexical-scopes-in-block-expression.rs:504:4, address = 0x00005555555556e7, resolved, hit count = 1
Hit breakpoint 16.1: where = a`lexical_scopes_in_block_expression::main::hcdd5c3caa9166e73 + 631 at lexical-scopes-in-block-expression.rs:510:8, address = 0x0000555555555497, resolved, hit count = 1
```
There are most `print` commands and their outputs before, and more `Hit breakpoint` messages afterwards, so I assume what happens is the `Hit breakpoint` messages should be interleaved but somehow they ended up being buffered after all of the other output.
As a stopgap measure I'm adding a newline before each `Hit breakpoint` so they don't end up on the same line as the last `print` output (which breaks our pattern-matching).
r? @michaelwoerister
test/c-variadic: Fix patterns on powerpc64
On architectures such as powerpc64 that use extend_integer_width_to in
their C ABI processing, integer parameters shorter than the native
register width will be annotated with the ArgAttribute::SExt or
ArgAttribute::ZExt attribute, and that attribute will be included in the
generated LLVM IR.
In this test, all relevant parameters are `i32`, which will get the
`signext` annotation on the relevant 64-bit architectures. Match both
the annotated and non-annotated case, but enforce that the annotation is
applied consistently.
Make `abs`, `wrapping_abs`, `overflowing_abs` const functions
This makes `abs`, `wrapping_abs` and `overflowing_abs` const functions like #58044 makes `wrapping_neg` and `overflowing_neg` const functions.
`abs` is made const by returning `(self ^ -1) - -1` = `!self + 1` = `-self` for negative numbers and `(self ^ 0) - 0` = `self` for non-negative numbers. The subexpression `self >> ($BITS - 1)` evaluates to `-1` for negative numbers and `0` otherwise. The subtraction overflows when `self` is `min_value()`, as we would be subtracting `max_value() - -1`; this is when `abs` should overflow.
`wrapping_abs` and `overflowing_abs` make use of `wrapping_sub` and `overflowing_sub` instead of the subtraction operator.
Allow cross-compiling doctests
This PR allows doctest to receive a --runtool argument, as well as possibly many --runtool-arg arguments, which are then used to run cross compiled doctests.
Also, functionality has been added to rustdoc to allow it to skip testing doctests on a per-target basis, in the same way that compiletest does it. For example, tagging the doctest with "ignore-sgx" disables testing on any targets that contain "sgx". A plain "ignore" still skips testing on all targets.
See [here](https://github.com/rust-lang/cargo/pull/6892) for the companion PR in the cargo project that extends functionality in Cargo so that it passes the appropriate parameters to rustdoc when cross compiling and testing doctests.
Part of [#6460](https://github.com/rust-lang/cargo/issues/6460)
This commit changes the HIR lowering around `await` so that temporary
lifetimes are extended. Previously, await was lowered as:
```rust
{
let mut pinned = future;
loop {
match ::std::future::poll_with_tls_context(unsafe {
<::std::pin::Pin>::new_unchecked(&mut pinned)
}) {
::std::task::Poll::Ready(result) => break result,
::std::task::Poll::Pending => {}
}
yield ();
}
}
```
With this commit, await is lowered as:
```rust
match future {
mut pinned => loop {
match ::std::future::poll_with_tls_context(unsafe {
<::std::pin::Pin>::new_unchecked(&mut pinned)
}) {
::std::task::Poll::Ready(result) => break result,
::std::task::Poll::Pending => {}
}
yield ();
}
}
```
However, this change has the following side-effects:
- All temporaries in future will be considered to live across a
yield for the purpose of auto-traits.
- Borrowed temporaries in future are likely to be considered to be live
across the yield for the purpose of the generator transform.
Signed-off-by: David Wood <david@davidtw.co>
This adds a new rustc target-configuration called 'i686-unknown_uefi'.
This is similar to existing x86_64-unknown_uefi target.
The i686-unknown-uefi target can be used to build Intel Architecture
32bit UEFI application. The ABI defined in UEFI environment (aka IA32)
is similar to cdecl.
We choose i686-unknown-uefi-gnu instead of i686-unknown-uefi to avoid
the intrinsics generated by LLVM. The detail of root-cause and solution
analysis is added as comment in the code.
For x86_64-unknown-uefi, we cannot use -gnu, because the ABI between
MSVC and GNU is totally different, and UEFI chooses ABI similar to MSVC.
For i686-unknown-uefi, the UEFI chooses cdecl ABI, which is same as
MSVC and GNU. According to LLVM code, the only differences between MSVC
and GNU are fmodf(f32), longjmp() and TLS, which have no impact to UEFI.
As such, using i686-unknown-uefi-gnu is the simplest way to pass the build.
Adding the undefined symbols, such as _aulldiv() to rust compiler-builtins
is out of scope. But it may be considered later.
The scope of this patch is limited to support target-configuration.
No standard library support is added in this patch. Such work can be
done in future enhancement.
Cc: Josh Triplett <josh.triplett@intel.com>
Reviewed-by: Josh Triplett <josh.triplett@intel.com>
On architectures such as powerpc64 that use extend_integer_width_to in
their C ABI processing, integer parameters shorter than the native
register width will be annotated with the ArgAttribute::SExt or
ArgAttribute::ZExt attribute, and that attribute will be included in the
generated LLVM IR.
In this test, all relevant parameters are `i32`, which will get the
`signext` annotation on the relevant 64-bit architectures. Match both
the annotated and non-annotated case, but enforce that the annotation is
applied consistently.
