Update GitHub pull request documentation link
It looks like the GitHub documentation has been re-organized so that the "fork and pull" model isn't explained alongside the PR process in one convenient link any more.
Check #[thread_local] statics correctly in the compiler.
Fixes#43733 by introducing `#[allow_internal_unsafe]` analogous to `#[allow_internal_unstable]`, for letting a macro expand to `unsafe` blocks and functions even in `#![forbid(unsafe_code)]` crates.
Fixes#17954 by not letting references to `#[thread_local]` statics escape the function they're taken in - we can't just use a magical lifetime because Rust has *lifetime parametrism*, so if we added the often-proposed `'thread` lifetime, we'd have no way to check it in generic code.
To avoid potential edge cases in the compiler, the lifetime is actually that of a temporary at the same position, i.e. `&TLS_STATIC` has the same lifetime `&non_const_fn()` would.
Referring to `#[thread_local]` `static`s at compile-time is banned now (as per PR discussion).
Additionally, to remove `unsafe impl Sync` from `std:🧵:local::fast::Key`, `#[thread_local]` statics are now not required to implement `Sync`, as they are not shared between threads.
- updates documentation on volatile memory intrinsics, now the case of
zero-sized types is mentioned explicitly.
Volatile memory operations which doesn't affect memory at all are omitted
in LLVM backend, e.g. if number of elements is zero or type used in
generic specialisation is zero-sized, then LLVM intrinsic or related code
is not generated. This was not explicitly documented before in Rust
documentation and potentially could cause issues.
- adds handling of zero-sized types for volatile_store.
- adds type size checks and warnigns for other volatile intrinsics.
- adds a test to check warnings emitting.
Cause of the issue
While preparing for trans_intrinsic_call() invoke arguments are
processed with trans_argument() method which excludes zero-sized types
from argument list (to be more correct - all arguments for which
ArgKind is Ignore are filtered out). As result volatile_store() intrinsic
gets one argument instead of expected address and value.
How it is fixed
Modification of the trans_argument() method may cause side effects,
therefore change was implemented in volatile_store() intrinsic building
code itself. Now it checks function signature and if it was specialised
with zero-sized type, then emits C_nil() instead of accessing
non-existing second argument.
Additionally warnings are added for all volatile operations which are
specialised with zero-sized arguments. In fact, those operations are omitted
in LLVM backend if no memory affected at all, e.g. number of elements
is zero or type is zero-sized. This was not explicitly documented before
and could lead to potential issues if developer expects volatile behaviour,
but type has degraded to zero-sized.
For box expressions, use NZ drop instead of a free block
This falls naturally out of making drop elaboration work with `box`
expressions, which is probably required for sane MIR borrow-checking.
This is a pure refactoring with no intentional functional effects.
r? @nagisa
None of these require a significant amount of code and using `#[inline]` will
allow constructors to get inlined, improving codegen at allocation callsites.
Improve LLVM/trans scheduling a bit
Currently it's possible that the main thread is waiting on LLVM threads to finish work while its implicit token is going to waste. This PR let's the main thread take over, so one of the running LLVM threads can free its token earlier.
r? @alexcrichton
Put `intrinsics::unreachable` on a possible path to stabilization
Mark it with the `unreachable` feature and put it into the `mem` module.
This is a pretty straight-forward API that can already be simulated in
stable Rust by using `transmute` to create an uninhabited enum that can
be matched.
AddValidation: handle Call terminators into blocks that have multiple incoming edges
The old code was just wrong: It would add validation on paths that don't even come from the call, and it would add multiple validations if multiple calls end return to the same block.
