[WIP] Support aarch64-pc-windows-gnu target #1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This makes sure that the tests in clippy_utils are run in CI. When looking into this I discovered that two tests were failing and multiple doc tests were failing. This fixes those tests and enables a few more doc tests.
…021-12-19 Subtree sync
Test clippy_utils in CI r? `@xFrednet` Since you did the last refactor of the `str_utils` functions in rust-lang#7873 changelog: Make sure tests in `clippy_utils` are passing by testing it in CI
Add suggestion for neg_multiply lint This fixes rust-lang#8115 by adding a suggestion for [neg_multiply]. My first issue on Github, any feedback or input is welcome 😃 changelog: create a suggestion for `neg_multiply`
Fixes rust-lang#92163 Fixes rust-lang#92014 When writing to the incremental cache, we encode all `Span`s we encounter, regardless of whether or not their `SourceFile` comes from the local crate, or from a foreign crate. When we decode a `Span`, we use the `StableSourceFileId` we encoded to locate the matching `SourceFile` in the current session. If this id corresponds to a `SourceFile` from another crate, then we need to have already imported that `SourceFile` into our current session. This usually happens automatically during resolution / macro expansion, when we try to resolve definitions from other crates. In certain cases, however, we may try to load a `Span` from a transitive dependency without having ever imported the `SourceFile`s from that crate, leading to an ICE. This PR fixes the issue by calling `imported_source_files()` when we encounter a `SourceFile` with a foreign `CrateNum`. This ensures that all `SourceFile`s from that crate are imported into the current session.
Fixes 5151 Details about the qualified path are now passed along so that rustfmt can include them when formatting struct literals.
…8472 Implement split_at_spare_mut without Deref to a slice so that the spare slice is valid ~I'm not sure I understand what's going on here correctly. And I'm pretty sure this safety comment needs to be changed. I'm just referring to the same thing that `as_mut_ptr_range` does.~ (Thanks `@RalfJung` for the guidance and clearing things up) I tried to run https://github.com/rust-lang/miri-test-libstd on alloc with -Zmiri-track-raw-pointers, and got a failure on the test `vec::test_extend_from_within`. I minimized the test failure into this program: ```rust #![feature(vec_split_at_spare)] fn main() { Vec::<i32>::with_capacity(1).split_at_spare_mut(); } ``` The problem is that the existing implementation is actually getting a pointer range where both pointers are derived from the initialized region of the Vec's allocation, but we need the second one to be valid for the region between len and capacity. (thanks Ralf for clearing this up)
Fix double space in pretty printed TryBlock Follow-up to rust-lang#92238 fixing one of the FIXMEs. ```rust macro_rules! repro { ($expr:expr) => { stringify!($expr) }; } fn main() { println!("{}", repro!(try {})); } ``` Before: <code>try {}</code> After: <code>try {}</code> The `head` helper already appends a space: https://github.com/rust-lang/rust/blob/2b67c30bfece00357d5fc09d99b49f21066f04ba/compiler/rustc_ast_pretty/src/pprust/state.rs#L654-L664 so doing `head` followed by `space` resulted in a double space: https://github.com/rust-lang/rust/blob/2b67c30bfece00357d5fc09d99b49f21066f04ba/compiler/rustc_ast_pretty/src/pprust/state.rs#L2241-L2242
Fix whitespace in pretty printed PatKind::Range Follow-up to rust-lang#92238 fixing one of the FIXMEs. ```rust macro_rules! repro { ($pat:pat) => { stringify!($pat) }; } fn main() { println!("{}", repro!(0..=1)); } ``` Before: `0 ..=1` After: `0..=1` The canonical spacing applied by rustfmt has no space after the lower expr. Rustc's parser diagnostics also do not put a space there: https://github.com/rust-lang/rust/blob/df96fb166f59431e3de443835e50d5b8a7a4adb0/compiler/rustc_parse/src/parser/pat.rs#L754
…toyo Sync rustc_codegen_gcc r? `@ghost` cc `@antoyo` `@rustbot` label +A-codegen +A-gcc +T-compiler
[rustc_builtin_macros] add indices to format_foreign::printf::Substitution::Escape Fixes rust-lang#92267. The problem was that the escape string "%%" does not need to appear at the very beginning of the format string, but the iterator implementation assumed that it did. The solution follows the pattern used by `format_foregin::shell::Subtitution::Escape`: https://github.com/rust-lang/rust/blob/8ed935e92dfb09ae388344b12284bf5110cf9265/compiler/rustc_builtin_macros/src/format_foreign.rs#L629
…k-Simulacrum Make tidy check for magic numbers that spell things Remove existing problematic cases. r? `@Mark-Simulacrum`
…askrgr Rollup of 7 pull requests Successful merges: - rust-lang#88310 (Lock bootstrap (x.py) build directory) - rust-lang#92097 (Implement split_at_spare_mut without Deref to a slice so that the spare slice is valid) - rust-lang#92412 (Fix double space in pretty printed TryBlock) - rust-lang#92420 (Fix whitespace in pretty printed PatKind::Range) - rust-lang#92457 (Sync rustc_codegen_gcc) - rust-lang#92460 ([rustc_builtin_macros] add indices to format_foreign::printf::Substitution::Escape) - rust-lang#92469 (Make tidy check for magic numbers that spell things) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Mark drop calls in landing pads `cold` instead of `noinline` Now that deferred inlining has been disabled in LLVM (rust-lang#92110), this shouldn't cause catastrophic size blowup. I confirmed that the test cases from rust-lang#41696 (comment) still compile quickly (<1s) after this change. ~Although note that I wasn't able to reproduce the original issue using a recent rustc/llvm with deferred inlining enabled, so those tests may no longer be representative. I was also unable to create a modified test case that reproduced the original issue.~ (edit: I reproduced it on CI by accident--the first commit timed out on the LLVM 12 builder, because I forgot to make it conditional on LLVM version) r? `@nagisa` cc `@arielb1` (this effectively reverts rust-lang#42771 "mark calls in the unwind path as !noinline") cc `@RalfJung` (fixes rust-lang#46515) edit: also fixes rust-lang#87055
Rustbuild already depends on once_cell which in the future can be replaced with std::lazy::Lazy.
The task of the macro is simple enough that a decl macro is almost ten times shorter than the original proc macro. The proc macro is 159 lines while the decl macro is just 18 lines. This reduces the amount of dependencies of rustbuild from 45 to 37. It also slight reduces compilation time from 47s to 44s for debug builds.
This slightly improves compilation time by reducing linking time (saving about a 1/10 of the the total compilation time after changing rustbuild) and slightly reduces disk usage (from 16MB for the rustc wrapper to 4MB).
rustc_metadata: Use a query for collecting all traits in encoder Implement refactoring suggested in rust-lang#92244 (comment) r? `@cjgillot`
…Simulacrum Remove CommandEnv::apply It's not being used and uses unsound set_var and remove_var functions. This is an internal function that isn't exported (even with `process_internals` feature), so this shouldn't break anything. Also see rust-lang#92365. Note that this isn't the only use of those methods in standard library, so that particular pull request will need more changes than just this to work (in particular, `test_capture_env_at_spawn` is using `set_var` and `remove_var`).
Clarify the guarantees that ThreadId does and doesn't make. The existing documentation does not spell out whether `ThreadId`s are unique during the lifetime of a thread or of a process. I had to examine the source code to realise (pleasingly!) that they're unique for the lifetime of a process. That seems worth documenting clearly, as it's a strong guarantee. Examining the way `ThreadId`s are created also made me realise that the `as_u64` method on `ThreadId` could be a trap for the unwary on those platforms where the platform's notion of a thread identifier is also a 64 bit integer (particularly if they happen to use a similar identifier scheme to `ThreadId`). I therefore think it's worth being even clearer that there's no relationship between the two.
…ound, r=dtolnay
Remove unnecessary bounds for some Hash{Map,Set} methods
This PR moves `HashMap::{into_keys,into_values,retain}` and `HashSet::retain` from `impl` blocks with `K: Eq + Hash, S: BuildHasher` into the blocks without them. It doesn't seem to me there is any reason these methods need to be bounded by that. This change brings `HashMap::{into_keys,into_values}` on par with `HashMap::{keys,values,values_mut}` which are not bounded either.
…mulacrum Reduce compile time of rustbuild Best reviewed commit by commit. The `ignore` crate and it's dependencies are probably responsible for the majority of the compile time after this PR. cc `@jyn514` as you got a couple of open rustbuild PR.
…r=jsha Add test for where clause order I didn't use ``@snapshot`` because of the ` ` characters, it's much simpler doing it through rustdoc-gui testsuite. r? `@camelid`
…ark-Simulacrum Enforce formatting for rustc_codegen_cranelift
…, r=joshtriplett Remove pronunciation guide from Vec<T> I performed an extremely scientific poll on twitter, and determined this is not how it's pronounced: https://twitter.com/at_tcsc/status/1476643344285581315
Emit an error for `--cfg=)` Fixes rust-lang#73026 See also: rust-lang#64467, rust-lang#89468 The issue stems from a `FatalError` being silently raised in `panictry_buffer`. Normally this is not a problem, because `panictry_buffer` emits the causes of the error, but they are not themselves fatal, so they get filtered out by the silent emitter. To fix this, we use a parser entrypoint which doesn't use `panictry_buffer`, and we handle the error ourselves.
…askrgr Rollup of 7 pull requests Successful merges: - rust-lang#84083 (Clarify the guarantees that ThreadId does and doesn't make.) - rust-lang#91593 (Remove unnecessary bounds for some Hash{Map,Set} methods) - rust-lang#92297 (Reduce compile time of rustbuild) - rust-lang#92332 (Add test for where clause order) - rust-lang#92438 (Enforce formatting for rustc_codegen_cranelift) - rust-lang#92463 (Remove pronunciation guide from Vec<T>) - rust-lang#92468 (Emit an error for `--cfg=)`) Failed merges: r? `@ghost` `@rustbot` modify labels: rollup
Remove effect of `#[no_link]` attribute on name resolution Previously it hid all non-macro names from other crates. This has no relation to linking and can change name resolution behavior in some cases (e.g. glob conflicts), in addition to just producing the "unresolved name" errors. I can kind of understand the possible reasoning behind the current behavior - if you can use names from a `no_link` crates then you can use, for example, functions too, but whether it will actually work or produce link-time errors will depend on random factors like inliner behavior. (^^^ This is not the actual reason why the current behavior exist, I've looked through git history and it's mostly accidental.) I think this risk is ok for such an obscure attribute, and we don't need to specifically prevent use of non-macro items from such crates. (I'm not actually sure why would anyone use `#[no_link]` on a crate, even if it's macro only, if you aware of any use cases, please share. IIRC, at some point it was used for crates implementing custom derives - the now removed legacy ones, not the current proc macros.) Extracted from rust-lang#91795.
dennisameling
force-pushed
the
aarch64-pc-windows-gnu
branch
from
fa59b8f to
9fad921
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is all a bit new to me so it took me quite some hours to get to the following:
rustup default nightly-aarch64-pc-windows-msvc- benefit of using the existing ARM64 support is that some parts in the compilation are sped up significantly as they run natively. I needed the nightly compiler because I had to dorustc -Z unstable-options --target=x86_64-pc-windows-gnu --print target-spec-json- not sure if I need it for further compilation steps as well or whether I can use beta/stable for thatmsys2_shell.cmd -use-full-pathand then didexport PATH=/clangarm64/bin:/clang64/bin:${PATH}to ensure I have all theclangarm64binaries available andclang64as a fallback (not strictly needed I think). This ensures that MSVC can also be found as I'm cross-compiling from there for nowconfig.toml, I prevented the CI LLVM from being downloaded because it missesllvm-tblgen.exe:config.toml:SourceFilein new context rust-lang/rust#92163 which I could fix by removing everything in thebuildfolder (except forbuild\aarch64-pc-windows-msvc\llvmbecause it takes ~2 hrs to build using the MSVC compiler, which can only cross-compile from x86 to arm64 and not build natively yet)aarch64-pc-windows-gnu, but that failed with (full log: llvm-windows-aarch64-gnu.txt)I had this in
config.toml: