| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
promote_consts: some clean-up after experimenting
This is some clean-up after experimenting in #125916,
Prefer to review commit-by-commit.
|
|
Rollup of 7 pull requests
Successful merges:
- #126380 (Add std Xtensa targets support)
- #126636 (Resolve Clippy `f16` and `f128` `unimplemented!`/`FIXME`s )
- #126659 (More status-quo tests for the `#[coverage(..)]` attribute)
- #126711 (Make Option::as_[mut_]slice const)
- #126717 (Clean up some comments near `use` declarations)
- #126719 (Fix assertion failure for some `Expect` diagnostics.)
- #126730 (Add opaque type corner case test)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Most modules have such a blank line, but some don't. Inserting the blank
line makes it clearer that the `//!` comments are describing the entire
module, rather than the `use` declaration(s) that immediately follows.
|
|
|
|
Wihout it, std keeps rebuiling when unchanged.
But we could use `--keep-stage=1` to make it not rebuild.
|
|
And remove the libc crate when it isn't needed
|
|
strict-provenance
|
|
SeqCst is unnecessary here.
|
|
std support for wasm32 panic=unwind
Tracking issue: #118168
This adds std support for `-Cpanic=unwind` on wasm, and with it slightly more fleshed out rustc support. Now, the stable default is still panic=abort without exception-handling, but if you `-Zbuild-std` with `RUSTFLAGS=-Cpanic=unwind`, you get wasm exception-handling try/catch blocks in the binary:
```rust
#[no_mangle]
pub fn foo_bar(x: bool) -> *mut u8 {
let s = Box::<str>::from("hello");
maybe_panic(x);
Box::into_raw(s).cast()
}
#[inline(never)]
#[no_mangle]
fn maybe_panic(x: bool) {
if x {
panic!("AAAAA");
}
}
```
```wat
;; snip...
(try $label$5
(do
(call $maybe_panic
(local.get $0)
)
(br $label$1)
)
(catch_all
(global.set $__stack_pointer
(local.get $1)
)
(call $__rust_dealloc
(local.get $2)
(i32.const 5)
(i32.const 1)
)
(rethrow $label$5)
)
)
;; snip...
```
|
|
|
|
|
|
|
|
|
|
|
|
Rename `static_mut_ref` lint to `static_mut_refs`.
|
|
This also takes care of other bootstrap-related changes.
|
|
|
|
Now that `unwind` supports Xous, enable unwinding panics on Xous.
Signed-off-by: Sean Cross <sean@xobs.io>
|
|
This bring unwind and personality code more in line with strict-provenance
|
|
|
|
|
|
|
|
It lints against features that are inteded to be internal to the
compiler and standard library. Implements MCP #596.
We allow `internal_features` in the standard library and compiler as those
use many features and this _is_ the standard library from the "internal to the compiler and
standard library" after all.
Marking some features as internal wasn't exactly the most scientific approach, I just marked some
mostly obvious features. While there is a categorization in the macro,
it's not very well upheld (should probably be fixed in another PR).
We always pass `-Ainternal_features` in the testsuite
About 400 UI tests and several other tests use internal features.
Instead of throwing the attribute on each one, just always allow them.
There's nothing wrong with testing internal features^^
|
|
|
|
It is no longer necessary as __rust_start_panic switched to the Rust abi.
|
|
|
|
Fix build of std for thumbv7a-pc-windows-msvc
Attempting to build std for the tier-3 target `thumbv7a-pc-windows-msvc` fails with the following error:
```
Building stage1 std artifacts (x86_64-pc-windows-msvc -> thumbv7a-pc-windows-msvc)
..
LLVM ERROR: WinEH not implemented for this target
error: could not compile `panic_unwind`
```
EH (unwinding) is not supported by LLVM for 32 bit arm msvc targets. This changes panic unwind to use the dummy implementation for `thumbv7a-pc-windows-msvc`.
|
|
|
|
After rust-lang/rust#101946 this completes the move to cfg-if 1.0 by:
* Updating getrandom 0.1.14->0.1.16
* Updating panic_abort, panic_unwind, and unwind to cfg-if 1.0
|
|
|
|
Co-authored-by: Amanieu d'Antras <amanieu@gmail.com>
|
|
|
|
|
|
Move EH personality functions to std
These were previously in the panic_unwind crate with dummy stubs in the
panic_abort crate. However it turns out that this is insufficient: we
still need a proper personality function even with -C panic=abort to
handle the following cases:
1) `extern "C-unwind"` still needs to catch foreign exceptions with -C
panic=abort to turn them into aborts. This requires landing pads and a
personality function.
2) ARM EHABI uses the personality function when creating backtraces.
The dummy personality function in panic_abort was causing backtrace
generation to get stuck in a loop since the personality function is
responsible for advancing the unwind state to the next frame.
Fixes #41004
|
|
|
|
The indirection is no longer needed since we always link to libgcc
even when the panic_abort runtime is used. Instead we can just call
the libgcc functions directly.
|
|
These were previously in the panic_unwind crate with dummy stubs in the
panic_abort crate. However it turns out that this is insufficient: we
still need a proper personality function even with -C panic=abort to
handle the following cases:
1) `extern "C-unwind"` still needs to catch foreign exceptions with -C
panic=abort to turn them into aborts. This requires landing pads and a
personality function.
2) ARM EHABI uses the personality function when creating backtraces.
The dummy personality function in panic_abort was causing backtrace
generation to get stuck in a loop since the personality function is
responsible for advancing the unwind state to the next frame.
|
|
|
|
|
|
This came up on armv7-apple-ios when using -Zbuild-std
|
|
|
|
|
|
|
|
|
|
This resolves #85821. See also the discussion here:
https://github.com/emscripten-core/emscripten/issues/17128
The consensus seems to be that rust_eh_personality is never invoked.
I patched __gxx_personality_v0 to log invocations and then ran
various panic tests and it was never called, so this analysis matches
what seems to happen in practice. This replaces the definition with
an abort, modeled on the structured exception handling implementation.
|
|
|
|
|
|
|
|
- Fix style errors.
- L4-bender does not yet support dynamic linking.
- Stack unwinding is not yet supported for x86_64-unknown-l4re-uclibc.
For now, just abort on panics.
- Use GNU-style linker options where possible. As suggested by review:
- Use standard GNU-style ld syntax for relro flags.
- Use standard GNU-style optimization flags and logic.
- Use standard GNU-style ld syntax for --subsystem.
- Don't read environment variables in L4Bender linker. Thanks to
CARGO_ENCODED_RUSTFLAGS introduced in #9601, l4-bender's arguments can
now be passed from the L4Re build system without resorting to custom
parsing of environment variables.
|
