Speed up tidy
This can be reviewed commit by commit since they contain separate optimizations.
```
# master
$ taskset -c 0-5 hyperfine './x test tidy'
Benchmark #1: ./x test tidy
Time (mean ± σ): 4.857 s ± 0.064 s [User: 12.967 s, System: 2.014 s]
Range (min … max): 4.779 s … 4.997 s 10 runs
# PR
$ taskset -c 0-5 hyperfine './x test tidy'
Benchmark #1: ./x test tidy
Time (mean ± σ): 3.672 s ± 0.035 s [User: 10.524 s, System: 2.029 s]
Range (min … max): 3.610 s … 3.725 s 10 runs
```
Add batch flag to remote-test-server
When using this flag, the stdout and stderr are sent in a single batch instead of being streamed. It also used `Command::output` instead of `Command::spawn`. This is useful for targets that might support std but not threading (Eg: UEFI).
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
Sync rustc_codegen_cranelift
This time there are a bunch of bugfixes, some new llvm intrinsic implementations and refactorings to the build system in preparation for running cg_clif tests as part of `./x.py test`.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
8 commits in 70898e522116f6c23971e2a554b2dc85fd4c84cd..cc0a320879c17207bbfb96b5d778e28a2c62030d
2022-12-05 19:43:44 +0000 to 2022-12-14 14:46:57 +0000
- artifact deps should works when target field specified coexists with `optional = true` (rust-lang/cargo#11434)
- Add `home` crate to cargo crates (rust-lang/cargo#11359)
- Use proper git URL for GitHub repos (rust-lang/cargo#11475)
- Fixes flock(fd, LOCK_UN) emulation on Solaris. (rust-lang/cargo#11474)
- Allow Check targets needed for optional doc-scraping to fail without killing the build (rust-lang/cargo#11450)
- fix: gleaning rustdocflags from `target.cfg(…)` is not supported (rust-lang/cargo#11323)
- Fix typo (rust-lang/cargo#11470)
- resolver.md: Fix naming in example (rust-lang/cargo#11469)
Combine `ty::Projection` and `ty::Opaque` into `ty::Alias`
Implements https://github.com/rust-lang/types-team/issues/79.
This PR consolidates `ty::Projection` and `ty::Opaque` into a single `ty::Alias`, with an `AliasKind` and `AliasTy` type (renamed from `ty::ProjectionTy`, which is the inner data of `ty::Projection`) defined as so:
```
enum AliasKind {
Projection,
Opaque,
}
struct AliasTy<'tcx> {
def_id: DefId,
substs: SubstsRef<'tcx>,
}
```
Since we don't have access to `TyCtxt` in type flags computation, and because repeatedly calling `DefKind` on the def-id is expensive, these two types are distinguished with `ty::AliasKind`, conveniently glob-imported into `ty::{Projection, Opaque}`. For example:
```diff
match ty.kind() {
- ty::Opaque(..) =>
+ ty::Alias(ty::Opaque, ..) => {}
_ => {}
}
```
This PR also consolidates match arms that treated `ty::Opaque` and `ty::Projection` identically.
r? `@ghost`
Remove `token::Lit` from `ast::MetaItemLit`.
Currently `ast::MetaItemLit` represents the literal kind twice. This PR removes that redundancy. Best reviewed one commit at a time.
r? `@petrochenkov`
When using this flag, the stdout and stderr is sent in a single batch
instead of being streamed. It also used `Command::output` instead of
`Command::spawn`. This is useful for targets that might support std
but not threading (Eg: UEFI).
Signed-off-by: Ayush Singh <ayushsingh1325@gmail.com>
Add LLVM KCFI support to the Rust compiler
This PR adds LLVM Kernel Control Flow Integrity (KCFI) support to the Rust compiler. It initially provides forward-edge control flow protection for operating systems kernels for Rust-compiled code only by aggregating function pointers in groups identified by their return and parameter types. (See llvm/llvm-project@cff5bef.)
Forward-edge control flow protection for C or C++ and Rust -compiled code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code share the same virtual address space) will be provided in later work as part of this project by identifying C char and integer type uses at the time types are encoded (see Type metadata in the design document in the tracking issue #89653).
LLVM KCFI can be enabled with -Zsanitizer=kcfi.
Thank you again, `@bjorn3,` `@eddyb,` `@nagisa,` and `@ojeda,` for all the help!
Clippy: backport ICE fix before beta branch
r? `@Manishearth`
Before beta is branched tomorrow we should backport the fix from https://github.com/rust-lang/rust-clippy/pull/10027 for an ICE. That way we'll get this into stable one release sooner.
This only cherry-picks the fix, not the tests for it. The proper sync of this will be done next week Thursday.
This commit adds LLVM Kernel Control Flow Integrity (KCFI) support to
the Rust compiler. It initially provides forward-edge control flow
protection for operating systems kernels for Rust-compiled code only by
aggregating function pointers in groups identified by their return and
parameter types. (See llvm/llvm-project@cff5bef.)
Forward-edge control flow protection for C or C++ and Rust -compiled
code "mixed binaries" (i.e., for when C or C++ and Rust -compiled code
share the same virtual address space) will be provided in later work as
part of this project by identifying C char and integer type uses at the
time types are encoded (see Type metadata in the design document in the
tracking issue #89653).
LLVM KCFI can be enabled with -Zsanitizer=kcfi.
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
make retagging work even with 'unstable' places
This is based on top of https://github.com/rust-lang/rust/pull/105301. Only the last two commits are new.
While investigating https://github.com/rust-lang/unsafe-code-guidelines/issues/381 I realized that we would have caught this issue much earlier if the add_retag pass wouldn't bail out on assignments of the form `*ptr = ...`.
So this PR changes our retag strategy:
- When a new reference is created via `Rvalue::Ref` (or a raw ptr via `Rvalue::AddressOf`), we do the retagging as part of just executing that address-taking operation.
- For everything else, we still insert retags -- these retags basically serve to ensure that references stored in local variables (and their fields) are always freshly tagged, so skipping this for assignments like `*ptr = ...` is less egregious.
r? ```@oli-obk```
Add prototype to generate `COPYRIGHT` from REUSE metadata
This PR adds a prototype to generate the `COPYRIGHT` file from the metadata gathered with REUSE. There are two new tools:
* `src/tools/collect-license-metadata` invokes REUSE, parses its output and stores a concise JSON representation of the metadata in `src/etc/license-metadata.json`.
* `src/tools/generate-copyright` parses the metadata generated above, (in the future will) gather crate dependencies metadata, and renders the `COPYRIGHT.md` file.
Note that since the contents of those files are currently incorrect, rather than outputting in the paths above, the files will be stored in `build/` and not committed. This will be changed once we're confident about the metadata.
Eventually, `src/etc/license-metadata.json` will be committed into the repository and verified to be up to date by CI (similar to our GitHub Actions configuration), to avoid having people install REUSE on their local machine in most cases.
You can see the (incorrect) generated files in https://gist.github.com/pietroalbini/3f3f22b6f9cc8533abf7494b6a50cf97.
r? `@pnkfelix`
