* Update bootstrap compiler
* Update version to 1.33.0
* Remove some `#[cfg(stage0)]` annotations
Actually updating the version number is blocked on updating Cargo
Fix gpg signing in manifest builder
GPG versions 2.x+ require that --batch be passed if --passphrase-fd is
to be accepted.
From the man page:
--passphrase-fd n
Read the passphrase from file descriptor n. Only the first line
will be read from file descriptor n. If you use 0 for n, the
passphrase will be read from STDIN. This can only be used if
only one passphrase is supplied.
Note that this passphrase is only used if the option --batch has
also been given. This is different from GnuPG version 1.x.
std: Depend directly on crates.io crates
Ever since we added a Cargo-based build system for the compiler the
standard library has always been a little special, it's never been able
to depend on crates.io crates for runtime dependencies. This has been a
result of various limitations, namely that Cargo doesn't understand that
crates from crates.io depend on libcore, so Cargo tries to build crates
before libcore is finished.
I had an idea this afternoon, however, which lifts the strategy
from #52919 to directly depend on crates.io crates from the standard
library. After all is said and done this removes a whopping three
submodules that we need to manage!
The basic idea here is that for any crate `std` depends on it adds an
*optional* dependency on an empty crate on crates.io, in this case named
`rustc-std-workspace-core`. This crate is overridden via `[patch]` in
this repository to point to a local crate we write, and *that* has a
`path` dependency on libcore.
Note that all `no_std` crates also depend on `compiler_builtins`, but if
we're not using submodules we can publish `compiler_builtins` to
crates.io and all crates can depend on it anyway! The basic strategy
then looks like:
* The standard library (or some transitive dep) decides to depend on a
crate `foo`.
* The standard library adds
```toml
[dependencies]
foo = { version = "0.1", features = ['rustc-dep-of-std'] }
```
* The crate `foo` has an optional dependency on `rustc-std-workspace-core`
* The crate `foo` has an optional dependency on `compiler_builtins`
* The crate `foo` has a feature `rustc-dep-of-std` which activates these
crates and any other necessary infrastructure in the crate.
A sample commit for `dlmalloc` [turns out to be quite simple][commit].
After that all `no_std` crates should largely build "as is" and still be
publishable on crates.io! Notably they should be able to continue to use
stable Rust if necessary, since the `rename-dependency` feature of Cargo
is soon stabilizing.
As a proof of concept, this commit removes the `dlmalloc`,
`libcompiler_builtins`, and `libc` submodules from this repository. Long
thorns in our side these are now gone for good and we can directly
depend on crates.io! It's hoped that in the long term we can bring in
other crates as necessary, but for now this is largely intended to
simply make it easier to manage these crates and remove submodules.
This should be a transparent non-breaking change for all users, but one
possible stickler is that this almost for sure breaks out-of-tree
`std`-building tools like `xargo` and `cargo-xbuild`. I think it should
be relatively easy to get them working, however, as all that's needed is
an entry in the `[patch]` section used to build the standard library.
Hopefully we can work with these tools to solve this problem!
[commit]: 28ee12db81
Ever since we added a Cargo-based build system for the compiler the
standard library has always been a little special, it's never been able
to depend on crates.io crates for runtime dependencies. This has been a
result of various limitations, namely that Cargo doesn't understand that
crates from crates.io depend on libcore, so Cargo tries to build crates
before libcore is finished.
I had an idea this afternoon, however, which lifts the strategy
from #52919 to directly depend on crates.io crates from the standard
library. After all is said and done this removes a whopping three
submodules that we need to manage!
The basic idea here is that for any crate `std` depends on it adds an
*optional* dependency on an empty crate on crates.io, in this case named
`rustc-std-workspace-core`. This crate is overridden via `[patch]` in
this repository to point to a local crate we write, and *that* has a
`path` dependency on libcore.
Note that all `no_std` crates also depend on `compiler_builtins`, but if
we're not using submodules we can publish `compiler_builtins` to
crates.io and all crates can depend on it anyway! The basic strategy
then looks like:
* The standard library (or some transitive dep) decides to depend on a
crate `foo`.
* The standard library adds
```toml
[dependencies]
foo = { version = "0.1", features = ['rustc-dep-of-std'] }
```
* The crate `foo` has an optional dependency on `rustc-std-workspace-core`
* The crate `foo` has an optional dependency on `compiler_builtins`
* The crate `foo` has a feature `rustc-dep-of-std` which activates these
crates and any other necessary infrastructure in the crate.
A sample commit for `dlmalloc` [turns out to be quite simple][commit].
After that all `no_std` crates should largely build "as is" and still be
publishable on crates.io! Notably they should be able to continue to use
stable Rust if necessary, since the `rename-dependency` feature of Cargo
is soon stabilizing.
As a proof of concept, this commit removes the `dlmalloc`,
`libcompiler_builtins`, and `libc` submodules from this repository. Long
thorns in our side these are now gone for good and we can directly
depend on crates.io! It's hoped that in the long term we can bring in
other crates as necessary, but for now this is largely intended to
simply make it easier to manage these crates and remove submodules.
This should be a transparent non-breaking change for all users, but one
possible stickler is that this almost for sure breaks out-of-tree
`std`-building tools like `xargo` and `cargo-xbuild`. I think it should
be relatively easy to get them working, however, as all that's needed is
an entry in the `[patch]` section used to build the standard library.
Hopefully we can work with these tools to solve this problem!
[commit]: 28ee12db81
Hopefully just another routine update!
So far this starts to enable the `std::arch` in stage0 builds of rustc.
This means that we may need stage0/not(stage0) in stdsimd itself, but
more and more code is starting to use `std::arch` so I think it's time
to start shifting the balance of work here.
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.
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
```
Fixes clippy toolstate.
Changes:
````
Remove -preview suffix from README
rustup clippy build with latest rustc (breakage due to 08f8faedd0 )
Forgot to remove some debugging code ...
Improved code noted by clippy.
Fix bug in `implicit_return`. Bug was already covered by test, but test was not checked for.
fix#3482 and add ui test for it
Don't change current working directory of cargo tests
Use cargo's "PROFILE" envvar and set CLIPPY_DOGFOOD
Use dogfood_runner for deterministic test ordering
Remove unnecessary documentation
Fix dogfood tests.
Added additional reasoning to `Why is this bad?`. Added comment to explain usage of MIR.
Renamed to `implicit_return`. Covered all other kinds besides `ExprKind::Lit`. Added check for replacing `break` with `return`.
Appeasing the Test Gods. Seems I'm not smart enough to run the tests locally before committing.
Renamed `forced_return` to `missing_returns`. Better clarification in the docs. Ran `update_lints`.
Added `FORCED_RETURN` lint.
````
Changes:
````
Fix ty::TyKind usage
Fix TyKind::<kind> usage in codebase
Extract single_match_else UI test
cargo fmt
Adds inequality cases to bool comparison lint
Remove unsafe_vector_initialization lint
Fix wildcard_dependencies false positive
Fix rustfmt format
Disable incremental build for windows
Travis: Add rustc sysroot bin to PATH for windows build
Fix some nursery links
Enforce LF lineendings for everything
Mention triage procedure in contributing.md
Keep testing large_digit_groups as ui test
Keep testing unsafe_vector_initialization as ui test
Downgrade large_digit_groups to pedantic
Downgrade unsafe_vector_initialization to restriction
remove macro_at_most_once_rep feature attribute since it's stable
Add missing word
Update docs in regards to the merged RFC
Document how to run rustfmt in CONTRIBUTING.md
Don't run integration tests in forks
Fix some formatting issues
Run rustfmt on clippy_lints
Run rustfmt on build.rs
Run rustfmt on clippy_dev
Run rustfmt on rustc_tools_util
Run rustfmt on src
Run rustfmt on the tests
Let travis run cargo fmt --all -- --check
Error on line overflow
````
Optimize local linkchecker program
I noticed on a [recent build][1] that the linkchecker stage of CI took a
whopping 15 minutes of CI time for something that should be near
instantaneous. Some local profiling showed some very hot functions and
clones which were pretty easy to remove, and now instead of running in
minutes locally it runs in seconds.
[1]: https://ci.appveyor.com/project/rust-lang/rust/build/job/kptifw1kb1nm4xuu
I noticed on a [recent build][1] that the linkchecker stage of CI took a
whopping 15 minutes of CI time for something that should be near
instantaneous. Some local profiling showed some very hot functions and
clones which were pretty easy to remove, and now instead of running in
minutes locally it runs in seconds.
[1]: https://ci.appveyor.com/project/rust-lang/rust/build/job/kptifw1kb1nm4xuu
libcore: Add VaList and variadic arg handling intrinsics
## Summary
- Add intrinsics for `va_start`, `va_end`, `va_copy`, and `va_arg`.
- Add `core::va_list::VaList` to `libcore`.
Part 1 of (at least) 3 for #44930
Comments and critiques are very much welcomed 😄
Changes:
````
Fix NAIVE_BYTECOUNT applicability
Fix dogfood error
Change Applicability of MISTYPED_LITERAL_SUFFIX
Add applicability level to (nearly) every span_lint_and_sugg function
Update stderr file
Fix bugs and improve documentation
Add Applicability::Unspecified to span_lint_and_sugg functions
Introduce snippet_with_applicability and hir_with_applicability functions
readme: tell how to install clippy on travis from git if it is not shipped with a nightly.
constants: add u128 i128 builtin types and fix outdated url
Update lints
Lint only the first statment/expression after alloc
Fix some warnings related to Self
Rename some symbols
Split lint into slow and unsafe vector initalization
Add unsafe set_len initialization
Add slow zero-filled vector initialization lint
Travis: Remove `sudo: false`
Downgrade needless_pass_by_value to allow by default
````
