Fix cross compilation of LLVM to aarch64 Windows targets
When cross-compiling, the LLVM build system recurses to build tools that need to run on the host system. However, since we pass cmake defines to set the compiler and target, LLVM still compiles these tools for the target system, rather than the host. The tools then fail to execute during the LLVM build.
This change sets defines for the tools that need to run on the host (llvm-nm, llvm-tablegen, and llvm-config), so that the LLVM build does not attempt to build them, and instead relies on the tools already built.
If compiling with clang-cl, adds the `--target` option to specify the target triple. MSVC compilers do not require this, since there is a separate compiler binary for each cross-compilation target.
Related issue: #72881
Requires LLVM change: rust-lang/llvm-project#67
When cross-compiling, the LLVM build system recurses to build tools
that need to run on the host system. However, since we pass cmake defines
to set the compiler and target, LLVM still compiles these tools for the
target system, rather than the host. The tools then fail to execute
during the LLVM build.
This change sets defines for the tools that need to run on the
host (llvm-nm, llvm-tablegen, and llvm-config), so that the LLVM build
does not attempt to build them, and instead relies on the tools already built.
If compiling with clang-cl, this change also adds the `--target` option
to specify the target triple. MSVC compilers do not require this, since there
is a separate compiler binary for cross-compilation.
This pulls in a fix for the install script on some tr(1) implementations,
as well as an update to use `anyhow` instead of `failure` for error
handling.
Update cargo, rls
## cargo
14 commits in c26576f9adddd254b3dd63aecba176434290a9f6..fede83ccf973457de319ba6fa0e36ead454d2e20
2020-06-23 16:21:21 +0000 to 2020-07-02 21:51:34 +0000
- Fix overflow error on 32-bit. (rust-lang/cargo#8446)
- Exclude the target directory from backups using CACHEDIR.TAG (rust-lang/cargo#8378)
- CONTRIBUTING.md: Link to Zulip rather than Discord (rust-lang/cargo#8436)
- Update built-in help for features (rust-lang/cargo#8433)
- Update core-foundation requirement from 0.7.0 to 0.9.0 (rust-lang/cargo#8432)
- Parse `# env-dep` directives in dep-info files (rust-lang/cargo#8421)
- Move string interning to util (rust-lang/cargo#8419)
- Expose built cdylib artifacts in the Compilation structure (rust-lang/cargo#8418)
- Remove unused serde_derive dependency from the crates.io crate (rust-lang/cargo#8416)
- Remove unused remove_dir_all dependency (rust-lang/cargo#8412)
- Improve git error messages a bit (rust-lang/cargo#8409)
- Improve the description of Config.home_path (rust-lang/cargo#8408)
- Improve support for non-`master` main branches (rust-lang/cargo#8364)
- Document that OUT_DIR in JSON messages is an absolute path (rust-lang/cargo#8403)
## rls
2020-06-19 15:36:00 +0200 to 2020-06-30 23:34:52 +0200
- Update cargo (rust-lang-nursery/rls#1686)
Update Chalk to 0.14
Not a ton here. Notable changes:
- Update to `0.14.0`
- New dependency on `tracing`, in `librustc_traits` only
- `FnAbi` from Chalk is `rustc_target::spec::abi::Abi`
- `Dynamic` actually lowers region
- Actually lower closures, with some tests. This doesn't 100% work, but can't confirm that's *only* because of closure lowering.
- Use `FxIndexSet` instead of `FxHashSet` in `chalk_fulfill`, which seems to have fixed the non-deterministic test error ordering. Guess we'll see on CI
- Actually implement `opaque_ty_data`, though I don't think this is sufficient for tests for them (I haven't added any)
- Uncomment some of the chalk tests that now work
r? @nikomatsakis
Implement mixed script confusable lint.
This implements the mixed script confusable lint defined in RFC 2457.
This is blocked on #72069 and https://github.com/unicode-rs/unicode-security/pull/13, and will need a Cargo.toml version bump after those are resolved.
The lint message warning is sub-optimal for now. We'll need a mechanism to properly output `AugmentScriptSet` to screen, this is to be added in `unicode-security` crate.
r? @Manishearth
Move remaining `NodeId` APIs from `Definitions` to `Resolver`
Implements https://github.com/rust-lang/rust/pull/73291#issuecomment-643515557
TL;DR: it moves all fields that are only needed during name resolution passes into the `Resolver` and keep the rest in `Definitions`. This effectively enforces that all references to `NodeId`s are gone once HIR lowering is completed.
After this, the only remaining work for #50928 should be to adjust the dev guide.
r? @petrochenkov
None of the tools seem to need syn 0.15.35, so we can just build syn
1.0.
This was causing an issue with clippy's `compile-test` program: since
multiple versions of `syn` would exist in the build directory, we would
non-deterministically pick one based on filesystem iteration order. If
the pre-1.0 version of `syn` was picked, a strange build error would
occur (see
https://github.com/rust-lang/rust/pull/73594#issuecomment-647671463)
To prevent this kind of issue from happening again, we now panic if we
find multiple versions of a crate in the build directly, instead of
silently picking the first version we find.
Upgrade Chalk
Things done in this PR:
- Upgrade Chalk to `0.11.0`
- Added compare-mode=chalk
- Bump rustc-hash in `librustc_data_structures` to `1.1.0` to match Chalk
- Removed `RustDefId` since the builtin type support is there
- Add a few more `FIXME(chalk)`s for problem spots I hit when running all tests with chalk
- Added some more implementation code for some newer builtin Chalk types (e.g. `FnDef`, `Array`)
- Lower `RegionOutlives` and `ObjectSafe` predicates
- Lower `Dyn` without the region
- Handle `Int`/`Float` `CanonicalVarKind`s
- Uncomment some Chalk tests that actually work now
- Remove the revisions in `src/test/ui/coherence/coherence-subtyping.rs` since they aren't doing anything different
r? @nikomatsakis
Diagnose use of incompatible sanitizers
Emit an error when incompatible sanitizer are configured through command
line options. Previously the last one configured prevailed and others
were silently ignored.
Additionally use a set to represent configured sanitizers, making it
possible to enable multiple sanitizers at once. At least in principle,
since currently all of them are considered to be incompatible with
others.
Emit an error when incompatible sanitizer are configured through command
line options. Previously the last one configured prevailed and others
were silently ignored.
Additionally use a set to represent configured sanitizers, making it
possible to enable multiple sanitizers at once. At least in principle,
since currently all of them are considered to be incompatible with
others.
Enable LVI hardening for x86_64-fortanix-unknown-sgx
This implements mitigations for the Load Value Injection vulnerability (CVE-2020-0551) for the `x86_64-fortanix-unknown-sgx` target by enabling new LLVM passes. More information about LVI and mitigations may be found at https://software.intel.com/security-software-guidance/insights/deep-dive-load-value-injection.
This PR unconditionally enables the mitigations for `x86_64-fortanix-unknown-sgx` since there is no available hardware that doesn't require the mitigations. This may be reconsidered in the future.
* [x] This depends on https://github.com/rust-lang/compiler-builtins/pull/359/
Update annotate-snippets-rs to 0.8.0
#59346
I made major changes to this library. In the previous version we worked with owned while in the current one with borrowed.
I have adapted it without changing the behavior.
I have modified the coverage since the previous one did not return correctly the index of the character in the line.
Recursively expand `TokenKind::Interpolated` in `probably_equal_for_proc_macro`
Fixes#68430
When comparing the captured and re-parsed `TokenStream` for a `TokenKind::Interpolated`, we currently treat any nested `TokenKind::Interpolated` tokens as unequal. If a `TokenKind::Interpolated` token shows up in the captured `TokenStream` due to a `macro_rules!` expansion, we will throw away the captured `TokenStream`, losing span information.
This PR recursively invokes `nt_to_tokenstream` on nested `TokenKind::Interpolated` tokens, effectively flattening the stream into a sequence of non-interpolated tokens. This allows it to compare equal with the re-parsed stream, allowing us to keep the original captured `TokenStream` (with span information).
This requires all of the `probably_equal_for_proc_macro` methods to be moved from `librustc_ast` to `librustc_parse` so that they can call `nt_to_tokenstream`.
