resolve: Reduce some clutter in import ambiguity errors
Noticed in https://www.reddit.com/r/rust/comments/a3pyrw/announcing_rust_131_and_rust_2018/eb8alhi/.
The first error is distracting, but unnecessary, it's a *consequence* of the ambiguity error and appears because one of the ambiguous `actix` modules (unsurprisingly) doesn't have the expected name in it.
codegen: Fix va_list - aarch64 iOS/Windows
## Summary
Fix code generated for `VaList` on Aarch64 iOS/Windows.
## Details
According to the [Apple - ARM64 Function Calling Conventions]:
> ... the type va_list is an alias for char * rather than for the struct
> type specified in the generic PCS.
The current implementation uses the generic Aarch64 structure for `VaList`
for Aarch64 iOS. Switch to using the `char *` variant of the `VaList`
and use the corresponding `emit_ptr_va_arg` for the `va_arg` intrinsic.
Windows always uses the `char *` variant of the `VaList`. Update the `va_arg`
intrinsic to use `emit_ptr_va_arg`.
[Apple - ARM64 Function Calling Conventions]: https://developer.apple.com/library/archive/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html
Improve the usage message for `-Z dump-mir`.
Ouput now looks like this:
```
$ rustc -Z help
...
-Z arg-align-attributes -- emit align metadata for reference arguments
-Z dump-mir=val -- dump MIR state to file.
`val` is used to select which passes and functions to dump. For example:
`all` matches all passes and functions,
`foo` matches all passes for functions whose name contains 'foo',
`foo & ConstProp` only the 'ConstProp' pass for function names containing 'foo',
`foo | bar` all passes for function names containing 'foo' or 'bar'.
-Z dump-mir-dir=val -- the directory the MIR is dumped into
...
```
Fixes#56558
use top level `fs` functions where appropriate
This commit replaces many usages of `File::open` and reading or writing
with `fs::read_to_string`, `fs::read` and `fs::write`. This reduces code
complexity, and will improve performance for most reads, since the
functions allocate the buffer to be the size of the file.
I believe that this commit will not impact behavior in any way, so some
matches will check the error kind in case the file was not valid UTF-8.
Some of these cases may not actually care about the error.
According to the Apple developer docs:
> The type va_list is an alias for char * rather than for the struct
> type specified in the generic PCS.
The current implementation uses the generic Aarch64 structure for VaList
for Aarch64 iOS.
Windows always uses the char * variant of the va_list.
This commit replaces many usages of `File::open` and reading or writing
with `fs::read_to_string`, `fs::read` and `fs::write`. This reduces code
complexity, and will improve performance for most reads, since the
functions allocate the buffer to be the size of the file.
I believe that this commit will not impact behavior in any way, so some
matches will check the error kind in case the file was not valid UTF-8.
Some of these cases may not actually care about the error.
Fix ICE with generators and NLL
Fix#55850.
This PR stops an ICE in #55850 by not panicking when a region cannot be named. However, this PR does not (yet) fix the underlying issue that the correct name for the test case provided for the issue (in this instance, `'a`) was not found.
This PR also lays a little bit of groundwork by categorizing yields separately from returns so that region naming can be specialized for this case.
r? @pnkfelix
This commit puts a fix in place for the ICE in region naming code so
that it doesn't break the compiler. However, this results in the
diagnostic being poorer as the borrow explanation that was causing the
ICE is not being added - this should be fixed as a follow-up.
Discard LLVM modules earlier when performing ThinLTO
Currently ThinLTO is performed by first compiling all modules (and keeping them in memory), and then serializing them into ThinLTO buffers in a separate, synchronized step. Modules are later read back from ThinLTO buffers when running the ThinLTO optimization pipeline.
We can also find the following comment in `lto.rs`:
// FIXME: right now, like with fat LTO, we serialize all in-memory
// modules before working with them and ThinLTO. We really
// shouldn't do this, however, and instead figure out how to
// extract a summary from an in-memory module and then merge that
// into the global index. It turns out that this loop is by far
// the most expensive portion of this small bit of global
// analysis!
I don't think that what is suggested here is the right approach: One of the primary benefits of using ThinLTO over ordinary LTO is that it's not necessary to keep all the modules (merged or not) in memory for the duration of the linking step.
However, we currently don't really make use of this (at least for crate-local ThinLTO), because we keep all modules in memory until the start of the LTO step. This PR changes the implementation to instead perform the serialization into ThinLTO buffers directly after the initial optimization step.
Most of the changes here are plumbing to separate out fat and thin lto handling in `write.rs`, as these now use different intermediate artifacts. For fat lto this will be in-memory modules, for thin lto it will be ThinLTO buffers.
r? @alexcrichton
Add SGX target to std and dependencies
This PR adds tier 3 `std` support for the `x86_64-fortanix-unknown-sgx` target.
### Background
Intel Software Guard Extensions (SGX) is an instruction set extension for x86 that allows executing code in fully-isolated *secure enclaves*. These enclaves reside in the address space of a regular user process, but access to the enclave's address space from outside (by e.g. the OS or a hypervisor) is blocked.
From within such enclaves, there is no access to the operating system or hardware peripherals. In order to communicate with the outside world, enclaves require an untrusted “helper” program that runs as a normal user process.
SGX is **not** a sandboxing technology: code inside SGX has full access to all memory belonging to the process it is running in.
### Overview
The Fortanix SGX ABI (compiler target `x86_64-fortanix-unknown-sgx`) is an interface for Intel SGX enclaves. It is a small yet functional interface suitable for writing larger enclaves. In contrast to other enclave interfaces, this interface is primarly designed for running entire applications in an enclave. The interface has been under development since early 2016 and builds on Fortanix's significant experience running enclaves in production.
Also unlike other enclave interfaces, this is the only implementation of an enclave interface that is nearly pure-Rust (except for the entry point code).
A description of the ABI may be found at https://docs.rs/fortanix-sgx-abi/ and https://github.com/fortanix/rust-sgx/blob/master/doc/FORTANIX-SGX-ABI.md.
The following parts of `std` are not supported and most operations will error when used:
* `std::fs`
* `std::process`
* `std::net::UdpSocket`
### Future plans
A separate PR (https://github.com/rust-lang/rust/pull/56067/) will add the SGX target to the rust compiler. In the very near future, I expect to upgrade this target to tier 2.
This PR is just the initial support to make things mostly work. There will be more work coming in the future, for example to add interfaces to the native SGX primitives, implement unwinding, optimize usercalls.
UDP and some form of filesystem support may be added in the future, but process support seems unlikely given the platform's constraints.
### Testing build
1. Install [Xargo](https://github.com/japaric/xargo): `cargo install xargo`
2. Create a new Cargo project, for example: `cargo new --bin sgxtest`.
3. Put the following in a file `Xargo.toml` next to your `Cargo.toml`:
```toml
[target.x86_64-fortanix-unknown-sgx.dependencies.std]
git = "https://github.com/jethrogb/rust"
branch = "jb/sgx-target"
```
NB. This can be quite slow. Instead, you can have a local checkout of that branch and use `path = "/path/to/rust/src/libstd"` instead. Don't forget to checkout the submodules too!
4. Build:
```sh
xargo build --target x86_64-fortanix-unknown-sgx
```
### Testing execution
Execution is currently only supported on x86-64 Linux, but support for Windows is planned.
1. Install pre-requisites. In order to test execution, you'll need to have a CPU with Intel SGX support. SGX support needs to be enabled in the BIOS. You'll also need to install the SGX driver and Platform Software (PSW) from [Intel](https://01.org/intel-software-guard-extensions).
2. Install toolchain, executor:
```sh
cargo install sgxs-tools --version 0.6.0-rc1
cargo install fortanix-sgx-tools --version 0.1.0-rc1
```
3. Start the enclave:
```sh
ftxsgx-elf2sgxs target/x86_64-fortanix-unknown-sgx/debug/sgxtest --heap-size 0x20000 --ssaframesize 1 --stack-size 0x20000 --threads 1 --debug
sgxs-append -i target/x86_64-fortanix-unknown-sgx/debug/sgxtest.sgxs
ftxsgx-runner target/x86_64-fortanix-unknown-sgx/debug/sgxtest.sgxs
```
Fix a stutter in the docs for slice::exact_chunks
Before this change, the docs for `slice::exact_chunks` reads like this:
> See `chunks` for a variant of this iterator that also returns the remainder as a smaller chunk, and `rchunks_exact` for the same iterator but starting at the end of the slice of the slice.
Notice that stutter at the end? This commit fixes it.
Send textual profile data to stderr, not stdout
This makes it possible to run with RUSTFLAGS="-Zself-profile" without
having to redirect compiler output; otherwise Cargo will error out due
to non-empty compiler stdout.
r? @wesleywiser
Replace usages of `..i + 1` ranges with `..=i`.
Before this change we were using old computer code techniques. After this change we use the new and improved computer code techniques.
Introduce ptr::hash for references
The RHS is what I used, which wasn't as convenient as `ptr::eq`, so I wondered: should `ptr::hash` exist?
My first Rust PR, so I'm going to need some guidance. :)
Add Armv8-M Mainline targets
This commit enables the Armv8-M Mainline architecture profile.
It adds two targets:
- `thumbv8m.main-none-eabi`
- `thumbv8m.main-none-eabihf`
The second one uses the Floating Point Unit for floating point
operations. It mainly targets the Cortex-M33 processor, which
can have the optional Floating Point Unit extension.
It follows #55041 which does it for Baseline. I will rebase this branch on top of it when it is merged to not create conflicts as we have some files in common. To make it work, it still relies on the Cargo change to be merged (accepting "." in target names, rust-lang/cargo#6255).
The goal would also be to add this target in the CI so that the `core` library is available for everybody. To do this, some changes will be needed to compile successfully the needed libraries:
* `cc-rs` needs to be updated to allow compiling C code for Armv8-M architectures profiles. It is only a few lines to add [here](a76611ad98/src/lib.rs (L1299)).
* Some assembly files in `builtins` in `compiler-rt` were not assembling for Armv8-M Mainline. I sent changes [upstream](https://reviews.llvm.org/D51854) to that project to fix that. The Rust version of `compiler-rt` will have to be updated to contain [that commit](a34cdf8bb4).
I tested it using the [Musca-A Test Chip board](https://developer.arm.com/products/system-design/development-boards/iot-test-chips-and-boards/musca-a-test-chip-board) but more intensively on the [Armv8-M FVP](https://developer.arm.com/products/system-design/fixed-virtual-platforms) (emulation platform). I am going to try to release my test code soon, once I tidy it up 👍
Unsupport `#[derive(Trait)]` sugar for `#[derive_Trait]` legacy plugin attributes
This is a long deprecated unstable feature that doesn't mesh well with regular resolution/expansion.
How to fix broken code:
- The recommended way is to migrate to stable procedural macros - derives or attributes (https://doc.rust-lang.org/nightly/book/first-edition/procedural-macros.html).
- If that's not possible right now for some reason, you can keep code working with a simple mechanical replacement `#[derive(Legacy)]` -> `#[derive_Legacy]`.
Closes https://github.com/rust-lang/rust/issues/29644
r? @ghost
Oliver Middleton