| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Mark format! with must_use hint
Uses unstable feature https://github.com/rust-lang/rust/issues/94745
Part of #126475
First contribution to rust, please let me know if the blessing of tests is correct
Thanks `@bjorn3` for the help
|
|
Support tail calls in mir via `TerminatorKind::TailCall`
This is one of the interesting bits in tail call implementation — MIR support.
This adds a new `TerminatorKind` which represents a tail call:
```rust
TailCall {
func: Operand<'tcx>,
args: Vec<Operand<'tcx>>,
fn_span: Span,
},
```
*Structurally* this is very similar to a normal `Call` but is missing a few fields:
- `destination` — tail calls don't write to destination, instead they pass caller's destination to the callee (such that eventual `return` will write to the caller of the function that used tail call)
- `target` — similarly to `destination` tail calls pass the caller's return address to the callee, so there is nothing to do
- `unwind` — I _think_ this is applicable too, although it's a bit confusing
- `call_source` — `become` forbids operators and is not created as a lowering of something else; tail calls always come from HIR (at least for now)
It might be helpful to read the interpreter implementation to understand what `TailCall` means exactly, although I've tried documenting it too.
-----
There are a few `FIXME`-questions still left, ideally we'd be able to answer them during review ':)
-----
r? `@oli-obk`
cc `@scottmcm` `@DrMeepster` `@JakobDegen`
|
|
|
|
- r-l/r 126784
- r-l/r 127113
- r-l/miri 3562
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Miri function identity hack: account for possible inlining
Having a non-lifetime generic is not the only reason a function can be duplicated. Another possibility is that the function may be eligible for cross-crate inlining. So also take into account the inlining attribute in this Miri hack for function pointer identity.
That said, `cross_crate_inlinable` will still sometimes return true even for `inline(never)` functions:
- when they are `DefKind::Ctor(..) | DefKind::Closure` -- I assume those cannot be `InlineAttr::Never` anyway?
- when `cross_crate_inline_threshold == InliningThreshold::Always`
so maybe this is still not quite the right criterion to use for function pointer identity.
|
|
|
|
This is an attempt to remove the magic from a lot of the numbers tested,
which should make things easier when it is time to add `f16` and `f128`.
A nice side effect is that these tests now cover all int <-> float
conversions with the same amount of tests.
Co-authored-by: Ralf Jung <post@ralfj.de>
|
|
r=RalfJung
TB: Refine protector end semantics
Tree Borrows has protector end tag semantics, namely that protectors ending cause a [special implicit read](https://perso.crans.org/vanille/treebor/diff.0.html) on all locations protected by that protector that have actually been accessed. See also #3067.
While this is enough for ensuring protectors allow adding/reordering reads, it does not prove that one can reorder writes. For this, we need to make this stronger, by making this implicit read be a write in cases when there was a write to the location protected by that protector, i.e. if the permission is `Active`.
There is a test that shows why this behavior is necessary, see `tests/fail/tree_borrows/protector-write-lazy.rs`.
|
|
|
|
|
|
Implement the `_mm256_zeroupper` and `_mm256_zeroall` intrinsics
These two intrinsics were missing from the original implementation of the AVX intrinsics.
Fortunately their implementation is trivial.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
This reverts commit 5c4ede88c61e746ed5c852d7a7e38ab1a824ae52, reversing
changes made to 95332b89187bb6a0c910574cfeff1933b619565a.
|
|
|
|
|
|
|
|
std: refactor the TLS implementation
As discovered by Mara in #110897, our TLS implementation is a total mess. In the past months, I have simplified the actual macros and their expansions, but the majority of the complexity comes from the platform-specific support code needed to create keys and register destructors. In keeping with #117276, I have therefore moved all of the `thread_local_key`/`thread_local_dtor` modules to the `thread_local` module in `sys` and merged them into a new structure, so that future porters of `std` can simply mix-and-match the existing code instead of having to copy the same (bad) implementation everywhere. The new structure should become obvious when looking at `sys/thread_local/mod.rs`.
Unfortunately, the documentation changes associated with the refactoring have made this PR rather large. That said, this contains no functional changes except for two small ones:
* the key-based destructor fallback now, by virtue of sharing the implementation used by macOS and others, stores its list in a `#[thread_local]` static instead of in the key, eliminating one indirection layer and drastically simplifying its code.
* I've switched over ZKVM (tier 3) to use the same implementation as WebAssembly, as the implementation was just a way worse version of that
Please let me know if I can make this easier to review! I know these large PRs aren't optimal, but I couldn't think of any good intermediate steps.
`@rustbot` label +A-thread-locals
|
|
tests for when a thread-local gets initialized in a tls dtor
|
|
|
|
|
|
don't ICE when encountering an extern type field during validation
"extern type" is a pain that keeps on giving...
Fixes https://github.com/rust-lang/rust/issues/126814
r? ```@oli-obk```
|
|
|
|
|
|
Implement LLVM x86 adx intrinsics
See title. It also explots a small opportunity to deduplicate a bit of intrinsics code.
|
|
|
|
|
|
Fix ICE caused by seeking past `i64::MAX`
Make Miri behave the same as standard library on file seeking offset.
Fixes #3680.
|
|
|
|
|
|
Implement LLVM x86 bmi intrinsics
This implements the intrinsics for both the bmi1 and bmi2 ISA extensions. All of these intrinsics live inside the same namespace as far as LLVM is concerned, which is why it is arguably better to bundle the implementations of these two extensions.
|
|
Stabilise `c_unwind`
Fix #74990
Fix #115285 (that's also where FCP is happening)
Marking as draft PR for now due to `compiler_builtins` issues
r? `@Amanieu`
|
|
|
|
|
|
StorageLive: refresh storage (instead of UB) when local is already live
Blocked on [this FCP](https://github.com/rust-lang/rust/issues/99160#issuecomment-2155924538), which also contains the motivation.
Fixes https://github.com/rust-lang/rust/issues/99160
Fixes https://github.com/rust-lang/rust/issues/98896 (by declaring it not-a-bug)
Fixes https://github.com/rust-lang/rust/issues/119366
Fixes https://github.com/rust-lang/unsafe-code-guidelines/issues/129
|
|
tell people how to set miri flags
fixes https://github.com/rust-lang/miri/issues/3677
|
|
|
|
Automatic Rustup
|
