This commit changes the ABI of SIMD types in the "Rust" ABI to unconditionally
be passed via pointers instead of being passed as immediates. This should fix a
longstanding issue, #44367, where SIMD-using programs ended up showing very odd
behavior at runtime because the ABI between functions was mismatched.
As a bit of a recap, this is sort of an LLVM bug and sort of an LLVM feature
(today's behavior). LLVM will generate code for a function solely looking at the
function it's generating, including calls to other functions. Let's then say
you've got something that looks like:
```llvm
define void @foo() { ; no target features enabled
call void @bar(<i64 x 4> zeroinitializer)
ret void
}
define void @bar(<i64 x 4>) #0 { ; enables the AVX feature
...
}
```
LLVM will codegen the call to `bar` *without* using AVX registers becauase `foo`
doesn't have access to these registers. Instead it's generated with emulation
that uses two 128-bit registers. The `bar` function, on the other hand, will
expect its argument in an AVX register (as it has AVX enabled). This means we've
got a codegen problem!
Comments on #44367 have some more contexutal information but the crux of the
issue is that if we want SIMD to work in general we'll need to ensure that
whenever a function calls another they ABI of the arguments being passed is in
agreement.
One possible solution to this would be to insert "shim functions" where whenever
a `target_feature` mismatch is detected the compiler inserts a shim function
where you pass arguments via memory to the shim and then the shim loads the
values and calls the target function (where the shim and the target have the
same target features enabled). This unfortunately is quite nontrivial to
implement in rustc today (especially when accounting for function pointers and
such).
This commit takes a different solution, *always* passing SIMD arguments through
memory instead of passing as immediates. This strategy solves the problem at the
LLVM layer because the ABI between two functions never uses SIMD registers. This
also shouldn't be a hit to performance because SIMD performance is thought to
often rely on inlining anyway, where a `call` instruction, even if using SIMD
registers, would be disastrous to performance regardless. LLVM should then be
more than capable of fixing all our memory usage to use registers instead after
enough inlining has been performed.
Note that there's a few caveats to this commit though:
* The "platform intrinsic" ABI is omitted from "always pass via memory". This
ABI is used to define intrinsics like `simd_shuffle4` where LLVM and rustc
need to have the arguments as an immediate.
* Additionally this commit does *not* fix the `extern` ("C") ABI. This means
that the bug in #44367 can still happen when using non-Rust-ABI functions. My
hope is that before stabilization we can ban and/or warn about SIMD types in
these functions (as AFAIK there's not much motivation to belong there anyway),
but I'll leave that for a later commit and if this is merged I'll file a
follow-up issue.
All in all this...
Closes#44367
Immovable generators
This adds support for immovable generators which allow you to borrow local values inside generator across suspension points. These are declared using a `static` keyword:
```rust
let mut generator = static || {
let local = &Vec::new();
yield;
local.push(0i8);
};
generator.resume();
// ERROR moving the generator after it has resumed would invalidate the interior reference
// drop(generator);
```
Region inference is no longer affected by the types stored in generators so the regions inside should be similar to other code (and unaffected by the presence of `yield` expressions). The borrow checker is extended to pick up the slack so interior references still result in errors for movable generators. This fixes#44197, #45259 and #45093.
This PR depends on [PR #44917 (immovable types)](https://github.com/rust-lang/rust/pull/44917), I suggest potential reviewers ignore the first commit as it adds immovable types.
renumber regions in generators
This fixes#47189, but I think we still have to double check various things around how to treat generators in MIR type check + borrow check (e.g., what borrows should be invalidated by a `Suspend`? What consistency properties should type check be enforcing anyway around the "interior" type?)
Also fixes#47587 thanks to @spastorino's commit.
r? @pnkfelix
check_match: fix handling of privately uninhabited types
the match-checking code used to use TyErr for signaling "unknown,
inhabited" types for a long time. It had been switched to using the
exact type in #38069, to handle uninhabited types.
However, in #39980, we discovered that we still needed the "unknown
inhabited" logic, but I used `()` instead of `TyErr` to handle that.
Revert to using `TyErr` to fix that problem.
Fixes#46964.
r? @nikomatsakis
remove bogus assertion and comments
The code (incorrectly) assumed that constants could not have generics
in scope, but it's not really a problem if they do.
Fixes#47153
r? @pnkfelix
Add transpose conversions for nested Option and Result
These impls are useful when working with combinator
methods that expect an option or a result, but you
have a `Result<Option<T>, E>` instead of an `Option<Result<T, E>>`
or vice versa.
avoid double-unsizing arrays in bytestring match lowering
The match lowering code, when lowering matches against bytestrings,
works by coercing both the scrutinee and the pattern to `&[u8]` and
then comparing them using `<[u8] as Eq>::eq`.
If the scrutinee is already of type `&[u8]`, then unsizing it is both
unneccessary and a trait error caught by the new and updated MIR typeck,
so this PR changes lowering to avoid doing that (match lowering tried to
avoid that before, but that attempt was quite broken).
Fixes#46920.
r? @eddyb
The match lowering code, when lowering matches against bytestrings,
works by coercing both the scrutinee and the pattern to `&[u8]` and
then comparing them using `<[u8] as Eq>::eq`.
If the scrutinee is already of type `&[u8]`, then unsizing it is both
unneccessary and a trait error caught by the new and updated MIR typeck,
so this PR changes lowering to avoid doing that (match lowering tried to
avoid that before, but that attempt was quite broken).
Fixes#46920.
Properly parse impls for the never type `!`
Recover from missing `for` in `impl Trait for Type`
Prohibit inherent default impls and default impls of auto traits
Change wording in more diagnostics to use "auto traits"
Some minor code cleanups in the parser
the match-checking code used to use TyErr for signaling "unknown,
inhabited" types for a long time. It had been switched to using the
exact type in #38069, to handle uninhabited types.
However, in #39980, we discovered that we still needed the "unknown
inhabited" logic, but I used `()` instead of `TyErr` to handle that.
Revert to using `TyErr` to fix that problem.
Treat #[path] files as mod.rs files
Fixes https://github.com/rust-lang/rust/issues/46936, cc @briansmith, @SergioBenitez, @nikomatsakis.
This (insta-stable) change treats files included via `#[path = "bla.rs"] mod foo;` as though they were `mod.rs` files. Namely, it allows them to include `mod` statements and looks for the child modules in sibling directories, rather than in relative `modname/childmodule.rs` files as happens for non-`mod.rs` files.
This change makes the `non_modrs_mods` feature backwards compatible with the existing usage in https://github.com/briansmith/ring, several versions of which are currently broken in beta. If we decide to merge, this change should be backported to beta.
cc https://github.com/rust-lang/rust/issues/37872
r? @jseyfried
macros: improve 1.0/2.0 interaction
This PR supports using unhygienic macros from hygienic macros without breaking the latter's hygiene.
```rust
// crate A:
#[macro_export]
macro_rules! m1 { () => {
f(); // unhygienic: this macro needs `f` in its environment
fn g() {} // (1) unhygienic: `g` is usable outside the macro definition
} }
// crate B:
#![feature(decl_macro)]
extern crate A;
use A::m1;
macro m2() {
fn f() {} // (2)
m1!(); // After this PR, `f()` in the expansion resolves to (2), not (3)
g(); // After this PR, this resolves to `fn g() {}` from the above expansion.
// Today, it is a resolution error.
}
fn test() {
fn f() {} // (3)
m2!(); // Today, `m2!()` can see (3) even though it should be hygienic.
fn g() {} // Today, this conflicts with `fn g() {}` from the expansion, even though it should be hygienic.
}
```
Once this PR lands, you can make an existing unhygienic macro hygienic by wrapping it in a hygienic macro. There is an [example](https://github.com/rust-lang/rust/pull/46551/commits/b766fa887dc0e4b923a38751fe4d570e35a75710) of this in the tests.
r? @nrc
These impls are useful when working with combinator
methods that expect an option or a result, but you
have a Result<Option<T>, E> instead of an Option<Result<T, E>>
or vice versa.
Fix built-in indexing not being used where index type wasn't "obviously" usize
Fixes#33903Fixes#46095
This PR was made possible thanks to the generous help of @eddyb
Following the example of binary operators, builtin checking for indexing has been moved from the typecheck stage to a writeback stage, after type constraints have been resolved.
Force appropriate extension when converting from int to ptr #43291Fixes#43291.
Looking for feedback if I've missed something and/or need to add more tests.
@eddyb @retep998 @nagisa @oli-obk
It looks like many of these tests are already disabled on emscripten,
which also doesn't seem to support environment variables and subprocess
spawning. Just add a similar tag for CloudABI. While there, sort some of
the lists of operating systems alphabetically.
Allow lifetimes in macros
This is a resurrection of PR #41927 which was a resurrection of #33135, which is intended to fix#34303.
In short, this allows macros_rules! to use :lifetime as a matcher to match 'lifetimes.
Still to do:
- [x] Feature gate
Add a tidy check for missing or too many trailing newlines.
I've noticed recently there are lots of review comments requesting to fix trailing newlines. If this is going to be an official style here, it's better to let the CI do this repetitive check.
Started rebasing @sgrif's PR #33135 off of current master. (Well, actually merging it into a new branch based off current master.)
The following files still need to be fixed or at least reviewed:
- `src/libsyntax/ext/tt/macro_parser.rs`: calls `Parser::parse_lifetime`, which doesn't exist anymore
- `src/libsyntax/parse/parser.rs`: @sgrif added an error message to `Parser::parse_lifetime`. Code has since been refactored, so I just took it out for now.
- `src/libsyntax/ext/tt/transcribe.rs`: This code has been refactored bigtime. Not sure whether @sgrif's changes here are still necessary. Took it out for this commit.
Implements RFC 1937: `?` in `main`
This is the first part of the RFC 1937 that supports new
`Termination` trait in the rust `main` function.
Thanks @nikomatsakis, @arielb1 and all other people in the gitter channel for all your help!
The support for doctest and `#[test]` is still missing, bu as @nikomatsakis said, smaller pull requests are better :)
rustc_trans: support ZST indexing involving uninhabited types.
Fixes#46855 in a minimal way. I decided against supporting non-memory `Rvalue::Len` in this PR (see https://github.com/rust-lang/rust/issues/46855#issuecomment-352965807), as `PlaceContext::Inspect` is also used for `Rvalue::Discriminant`.
r? @arielb1
