Experiment: Reborrow traits
With this PR we now have basic functional Reborrow and CoerceShared traits. The current limitations are:
1. Reborrowable types can only have one lifetime parameter, so as to avoid having to figure out and store in rmeta the information of which lifetimes weaken during reborrowing.
2. Reborrowing of `&mut` wrappers is working (though I've not tested generic wrappers like `Option<&mut T>` yet), but CoerceShared of `&mut` wrappers currently causes an ICE.
The remaining tasks to complete before I'd consider this PR mergeable are:
- [x] Fix ICE on CoerceShared. Unfortunately this might require dipping into rmeta.
- [x] Expand the tests to give a more complete view of the current state of the experiment.
Reborrow traits experiment: rust-lang/rust#145612
Co-authored by @dingxiangfei2009
Support `-Cpanic=unwind` on WASI targets
This commit is some minor updates/restructuring in a few locations with the end result being supporting `-Cpanic=unwind` on WASI targets. This continues to be off-by-default insofar as WASI targets default to `-Cpanic=abort`, meaning that actually using anything in this commit requires `-Zbuild-std`. Specifically the changes made here are:
* The self-contained sysroot for WASI targets now contains a copy of `libunwind.a` from wasi-sdk, first shipped with wasi-sdk-33 (also updated here).
* The `unwind` crate here in this repository uses the `libunwind` module instead of the custom bare-metal wasm implementation of exceptions. This means that Rust uses the `_Unwind_*` symbols which allows it to interoperate with C/C++/etc.
* Wasm targets are all updated to pass the LLVM argument `-wasm-use-legacy-eh=false` to differ from LLVM's/clang's default of using the legacy exception handling proposal for WebAssembly. This has no effect by default because `panic=abort` is used on most targets. Emscripten is exempted from this as the Emscripten target is explicitly intended to follow LLVM's/clang's defaults.
* There's a single test in the test suite that links to the `panic_unwind` crate which ended up requiring `-Wexceptions` from Wasmtime, so the test parts were updated and Wasmtime was updated in CI, too.
The net result of all of this is that this should not actually affect any WebAssembly target's default behavior. Optionally, though, WASI programs can be built with exception handling via:
RUSTFLAGS='-Cpanic=unwind' cargo +nightly run -Z build-std --target wasm32-wasip2
Effectively `-Zbuild-std` and `-Cpanic=unwind` is all that's necessary to enable this support on wasm targets.
Finally, this ends up closing rust-lang/rust#154593 as well. The WASI targets are now defined to use `-lunwind` to implement unwinding. This means that the in-tree definition of `__cpp_exception` is no longer of concern and the definition is always sourced externally. If Rust is linked with other C/C++ code using WASI then these idioms are compatible with wasi-sdk, for example, to use that as a linker. The main caveat is that when using an external linker the `-fwasm-exceptions` argument needs to be passed to `clang` for it to be able to find the `libunwind.a` library to link against.
Closesrust-lang/rust#154593
This commit is some minor updates/restructuring in a few locations with
the end result being supporting `-Cpanic=unwind` on WASI targets. This
continues to be off-by-default insofar as WASI targets default to
`-Cpanic=abort`, meaning that actually using anything in this commit
requires `-Zbuild-std`. Specifically the changes made here are:
* The self-contained sysroot for WASI targets now contains a copy of
`libunwind.a` from wasi-sdk, first shipped with wasi-sdk-33 (also
updated here).
* The `unwind` crate here in this repository uses the `libunwind` module
instead of the custom bare-metal wasm implementation of exceptions.
This means that Rust uses the `_Unwind_*` symbols which allows it to
interoperate with C/C++/etc.
* Wasm targets are all updated to pass the LLVM argument
`-wasm-use-legacy-eh=false` to differ from LLVM's/clang's default of
using the legacy exception handling proposal for WebAssembly. This has
no effect by default because `panic=abort` is used on most targets.
Emscripten is exempted from this as the Emscripten target is
explicitly intended to follow LLVM's/clang's defaults.
* There's a single test in the test suite that links to the
`panic_unwind` crate which ended up requiring `-Wexceptions` from
Wasmtime, so the test parts were updated and Wasmtime was updated in
CI, too.
The net result of all of this is that this should not actually affect
any WebAssembly target's default behavior. Optionally, though, WASI
programs can be built with exception handling via:
RUSTFLAGS='-Cpanic=unwind' cargo +nightly run -Z build-std --target wasm32-wasip2
Effectively `-Zbuild-std` and `-Cpanic=unwind` is all that's necessary
to enable this support on wasm targets.
Finally, this ends up closing 154593 as well. The WASI targets are now
defined to use `-lunwind` to implement unwinding. This means that the
in-tree definition of `__cpp_exception` is no longer of concern and the
definition is always sourced externally. If Rust is linked with other
C/C++ code using WASI then these idioms are compatible with wasi-sdk,
for example, to use that as a linker. The main caveat is that when using
an external linker the `-fwasm-exceptions` argument needs to be passed
to `clang` for it to be able to find the `libunwind.a` library to link
against.
Closes 154593
Add better default spans for the `Ty` impl of `QueryKey`
This add default spans for `Ty` in its implementation of `QueryKey`. This is useful so we can get spans for the `layout_of` query which shows up in cycle errors.
CFI: Fix LTO for `#![no_builtins]` crates with CFI
Fixes LTO for `#![no_builtins]` crates with CFI enabled by using rustc's `EmitObj::Bitcode` path (and emitting LLVM bitcode in the `.o` for linker-based LTO).
It also adds tests that verify that the examples in [rust-cfi-examples](https://github.com/rcvalle/rust-cfi-examples) build and run with `-Zbuild-std` to prevent other future regressions.
Deny warnings in the test for crates that are available on stable
We've got a couple of crates, like `rustc_type_ir` that have parts disabled on stable. I believe part of this is so, for example, rust-analyzer can use bits of the compiler. We previously allowed warnings here, and I ran into one. This denies warnings in the test that compiles these stable crates (I chose not to on the crate itself, so you don't *constantly* run into the warnings if you have turned that off in `config.toml`). This test doesn't run by default, but it does run in CI.
Lint unused pub items in binary crates
~~This PR adds a new unstable flag -Ztreat-pub-as-pub-crate as [@Kobzol](https://github.com/Kobzol) suggested.~~
~~When compiling binary crates with this flag, the seed worklist will only contain the entry fn and won't contain other reachable items. Then we can do the dead code analysis for pub items just like they are pub(crate).~~
Related zulip thread [#general > pub/pub(crate) within a binary is a footgun](https://rust-lang.zulipchat.com/#narrow/channel/122651-general/topic/pub.2Fpub.28crate.29.20within.20a.20binary.20is.20a.20footgun/with/558931034).
---
Updated:
Adds a new lint `unused_pub_items_in_binary` (crate-level, default allow for now) instead of the previous unstable flag to lint unused `pub` items for binary crates.
See more details of implementation in https://github.com/rust-lang/rust/pull/149509#issuecomment-4102337689.
This lint is allowed by default, but I believe this has been better than the unstable flag. Making it warn-by-default will lead to a lot of noise for this PR (like bless many tests). So I'd like to make it warn-by-default in a separate PR in the future.
change the type of the argument of `drop_in_place` lang item to `&mut _`
We used to special case `core::ptr::drop_in_place` when computing LLVM argument attributes with this hack:
https://github.com/rust-lang/rust/blob/db5e2dc248fe5bb26f70d7baec46a3bca9fa3e1d/compiler/rustc_ty_utils/src/abi.rs#L383-L392
This is because even though `drop_in_place` takes a `*mut T` it is semantically a `&mut T` (remember how `&mut Self` is passed to `Drop::drop`). This is apparently relevant for perf.
This PR replaces this hack with a simpler solution -- it makes `drop_in_place` a thin wrapper around newly added `core::ptr::drop_glue`, which is the actual lang item and takes a `&mut T`:
https://github.com/rust-lang/rust/blob/d2563d5003bbecff1efc40c1f5673ceec603825b/library/core/src/ptr/mod.rs#L810-L833
------
The rest of the PR is blessing tests and cleaning up things which are not necessary after this change.
One thing that is a bit awkward is that now that `drop_glue` is the actual lang item, a lot of the comments referring to `drop_in_place` are outdated. Should I try fixing that?
I've also changed `async_drop_in_place` to take a `&mut T`, and it simplified the code handling it a bit. (since it's unstable we don't need to introduce a wrapper)
-------
cc @RalfJung
Closes https://github.com/rust-lang/rust/issues/154274
Fixes LTO for `#![no_builtins]` crates with CFI enabled by using rustc's
`EmitObj::Bitcode` path (and emitting LLVM bitcode in the `.o` for
linker-based LTO).
tests/ui: allow spaces in hashbrown src normalization
If one's home directory contains a space, the default location for the hashbrown source location also contains a space, and so the UI test normalization in issue-21763 fails to normalize as expected.
While this new regex does not handle all valid paths, such as those beginning with `\\?\` or `\\name\`, this handles most absolute UNIX and Windows paths. Relative paths don't seem to be applicable.
Don't return dummy MacroData in `get_macro`
I was experimenting with tool attributes and ast manipulation, and wasted some time figuring out that this was happening. AFAIK all users of `get_macro` are expecting an actual macro (and none were reading the dummy MacroData) so there should be no change in behavior.
Improve caching by introducing `TypingMode::ErasedNotCoherence`
r? @lcnr
This introduces `TypingMode::ErasedNotCoherence`. Most typing modes contain a list of opaque types, which are quite often unused during canonicalization. With this change, any time we try canonicalization, we replace whichever typing mode we're currently in with `ErasedNotcoherence`, attempt to canonicalize, and if that fails *retry* in the original typing mode. If erased mode succeeds, this is beneficial because that way the opaque types don't end up in the cache key, allowing more cache reuse.
This seems to have a small (0.5%) slowdown on most programs, but a dramatic (>60%) speedup in specific cases like the rustc-perf `wg-grammar` benchmark. Some more improvements are expected with "eager normalization", which is work that's under way right now.
add known-bug test for coroutine 'static-yields-non-'static unsoundness (#144442)
Add a `known-bug` regression test for [#144442 ("Unsoundness due to 'static coroutines that yield non-'static values").](https://github.com/rust-lang/rust/issues/144442)
Existing known-bug tests:
```
- tests/ui/closures/static-closures-with-nonstatic-return.rs
- tests/ui/implied-bounds/dyn-erasure-tait.rs
- tests/ui/implied-bounds/dyn-erasure-no-tait.rs
```
Verified in Darwin: running the compiled binary segfaults on current main, so the bug is still present.
Always use `ConstFn` context for `const` closures
fixesrust-lang/rust#155803
Since https://github.com/rust-lang/rust/commit/e8a46117795f82f35e2f4087516a8743e28ba174, `hir_body_const_context()` returned the parent's const context for a `const` closure. But a `const` closure can escape its enclosing body via a `fn`-pointer-typed const item or an opaque return type and be invoked at runtime, so it must be const-checked under the most restrictive `ConstFn` context like a regular `const fn`.
r? oli-obk (since you authored the commit mentioned above, feel free to reroll)
generic_const_args: allow paths to non type consts
tracking issue: https://github.com/rust-lang/rust/issues/151972
Non type consts should be usable in the type system in `feature(generic_const_args)`. These are directly plugged into the constant evaluator, unlike type consts, which are attempted to be reasoned about by the type system.
Inherent associated constants are not supported at this time, due to complications around how generic arguments are represented for them (it's currently a mess). The mess is being cleaned up (e.g. https://github.com/rust-lang/rust/pull/154758), so instead of trying to hack support in before the refactoring is done, let's just wait to be able to implement it more cleanly.
r? @BoxyUwU
fix: more descriptive error message for enum to integer
Fixesrust-lang/rust#151116
A more descriptive error message when casting an enum to an Integer. Please review issue linked above.
If one's home directory contains a space, the default location for the
hashbrown source location also contains a space, and so the UI test
normalization in issue-21763 fails to normalize as expected.
While this new regex does not handle all valid paths, such as those
beginning with `\\?\` or `\\name\`, this handles most absolute UNIX and
Windows paths. Relative paths don't seem to be applicable.
bors