| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
Bump to 1.31.0 and bootstrap from 1.30 beta
Closes #54594.
|
|
Revert most of MaybeUninit, except for the new API itself
This reverts most of https://github.com/rust-lang/rust/pull/53508/ for perf reasons (first commit reverts that entire PR), except for the new API itself (added back in 2nd commit).
|
|
This reverts commit c6e3d7fa3113aaa64602507f39d4627c427742ff, reversing
changes made to 4591a245c7eec9f70d668982b1383cd2a6854af5.
|
|
|
|
MSVC ignores these keywords for C/C++ and uses the standard system
calling convention. Rust should do so as well.
Fixes #54569.
|
|
|
|
Use no_default_libraries for all NetBSD flavors
The no_default_libraries was introduced in #28578 because the
NetBSD-based rumprun needed to disable the link flag.
This moves the definition to be used by all NetBSD linker flavors to
close #49627.
A different solution would be adding -lc but as there is no platform
with explicit -lc, this approach is used.
|
|
The no_default_libraries was introduced in #28578 because the
NetBSD-based rumprun needed to disable the link flag.
This moves the definition to be used by all NetBSD linker flavors to
close #49627.
A different solution would be adding -lc but as there is no platform
with explicit -lc, this approach is used.
|
|
to work better.
|
|
Add target thumbv7a-pc-windows-msvc
This is an early draft of support for Windows/ARM. To test it,
1. Install Visual Studio 2017 and Windows SDK version 17134.
1. Obtain alexcrichton/xz2-rs#35, rust-lang-nursery/compiler-builtins#256, and the fix for [LLVM Bug 38620](https://bugs.llvm.org/show_bug.cgi?id=38620).
2. Open a command prompt and run
```
set CC_thumbv7a-pc-windows-msvc=C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Tools\MSVC\14.11.25503\bin\HostX64\arm\CL.exe
set CFLAGS_thumbv7a-pc-windows-msvc=/D_ARM_WINAPI_PARTITION_DESKTOP_SDK_AVAILABLE=1 /nologo
c:\python27\python.exe x.py build --host x86_64-pc-windows-msvc --build x86_64-pc-windows-msvc --target thumbv7a-pc-windows-msvc
```
It will build the stage 2 compiler, but fail building stage 2 test. To build an executable targeting windows/arm,
1. Copy `build\x86_64-pc-windows-msvc\stage0\bin\cargo.exe` to `build\x86_64-pc-windows-msvc\stage2\bin`
2. Open a command prompt and run
```
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\VC\Auxiliary\Build\vcvars64.bat"
set PATH=build\x86_64-pc-windows-msvc\stage2\bin;%PATH%
cargo new hello
cd hello
cargo build --target thumbv7a-pc-windows-msvc –release
```
Copy target\thumbv7a-pc-windows-msvc\release\hello.exe to your platform and run.
There are a number of open issues that I'm hoping to get help with:
- Error when compiling the `test` crate: `error: cannot link together two panic runtimes: panic_abort and panic_unwind`
- Warnings when building the compiler_builtins crate: `warning: cl : Command line warning D9002 : ignoring unknown option '-fvisibility=hidden'`. It looks like the build system is passing GCC-style flags to MSVC.
- How to specify the LIBPATH entries for ARM. Right now they are hardcoded as absolute paths in the target spec.
This pull request depends on
- alexcrichton/xz2-rs#35 - update vcxproj to Visual Studio 2017
- rust-lang-nursery/compiler-builtins#256 - fix compile errors when building for windows/arm
- [Bug 38620 - ARM: Incorrect COFF relocation type for thumb bl instruction](https://bugs.llvm.org/show_bug.cgi?id=38620)
This PR updates #52659
|
|
|
|
stabilize outlives requirements
https://github.com/rust-lang/rust/issues/44493
r? @nikomatsakis
|
|
Fix a few AMDGPU related issues
* AMDGPU ignores `noinline` and sadly doesn't clear the attribute when it slaps `alwaysinline` on everything,
* an AMDGPU related load bit range metadata assertion,
* I didn't enable the `amdgpu` component in the `librustc_llvm` build script,
* Add AMDGPU call abi info.
|
|
Co-authored-by: nikomatsakis
|
|
|
|
|
|
rustc: Prepare the `atomics` feature for wasm
This commit adds a few changes for atomic instructions on the
`wasm32-unknown-unknown` target. Atomic instructions are not yet stable in
WebAssembly itself but there are multiple implementations and LLVM has support
for the proposed instruction set, so let's work on exposing it!
Here there are a few inclusions:
* The `atomics` feature was whitelisted for LLVM, allowing code in Rust to
enable/disable/gate on this.
* The `singlethread` option is turned off for wasm when the `atomics` feature is
enabled. This means that by default wasm won't be lowering with atomics, but
when atomics are enabled globally we'll turn off single-threaded mode to
actually codegen atomics. This probably isn't what we'll want in the long term
but for now it should work.
* Finally the maximum atomic width is increased to 64 to reflect the current
wasm spec.
|
|
|
|
Implement the `min_const_fn` feature gate
cc @RalfJung @eddyb
r? @Centril
implements the feature gate for #53555
I added a hack so the `const_fn` feature gate also enables the `min_const_fn` feature gate. This ensures that nightly users of `const_fn` don't have to touch their code at all.
The `min_const_fn` checks are run first, and if they succeeded, the `const_fn` checks are run additionally to ensure we didn't miss anything.
|
|
This commit adds a few changes for atomic instructions on the
`wasm32-unknown-unknown` target. Atomic instructions are not yet stable in
WebAssembly itself but there are multiple implementations and LLVM has support
for the proposed instruction set, so let's work on exposing it!
Here there are a few inclusions:
* The `atomics` feature was whitelisted for LLVM, allowing code in Rust to
enable/disable/gate on this.
* The `singlethread` option is turned off for wasm when the `atomics` feature is
enabled. This means that by default wasm won't be lowering with atomics, but
when atomics are enabled globally we'll turn off single-threaded mode to
actually codegen atomics. This probably isn't what we'll want in the long term
but for now it should work.
* Finally the maximum atomic width is increased to 64 to reflect the current
wasm spec.
|
|
|
|
|
|
|
|
|
|
|
|
add more Cortex-R targets
This expands on PR #53663 to complete the set of Cortex-R targets and builds
rust-std components for them.
r? @alexcrichton
each extra rust-std component (there's 4 of them) takes about 3 minutes to build
on my local machine. In terms of stability (LLVM codegen bugs) these new targets
should be as stable as the Cortex-M ones (e.g. `thumbv7m-none-eabi`).
If the extra build time is too much we can leave the rust-std components out for
now
closes #53663
cc @paoloteti
|
|
fix for late-bound regions
Fix for https://github.com/rust-lang/rust/issues/53419
r? @nikomatsakis
|
|
|
|
|
|
|
|
by removing the redundant +v7 feature
|
|
|
|
Similar to `armebv7r-none-eabihf`, but for Little-endian MCUs.
As example TI RM4x/RM5x are Little-endian Cortex-R4F/R5F MCUs.
CI/Dockerfile is intentionally in the disabled folder.
|
|
|
|
to rust-lld so users won't need an external linker to build programs
|
|
or "".into()
|
|
|
|
try to infer linker flavor from linker name and vice versa
This is a second take on PR #50359 that implements the logic proposed in https://github.com/rust-lang/rust/pull/50359#pullrequestreview-116663121
With this change it would become possible to link `thumb*` binaries using GNU's LD on stable as `-C linker=arm-none-eabi-ld` would be enough to change both the linker and the linker flavor from their default values of `arm-none-eabi-gcc` and `gcc`.
To link `thumb*` binaries using rustc's LLD on stable `-Z linker-flavor` would need to be stabilized as `-C linker=rust-lld -Z linker-flavor=ld.lld` are both required to change the linker and the linker flavor, but this PR doesn't propose that. We would probably need some sort of stability guarantee around `rust-lld`'s name and availability to make linking with rustc's LLD truly stable.
With this change it would also be possible to link `thumb*` binaries using a system installed LLD on stable using the `-C linker=ld.lld` flag (provided that `ld.lld` is a symlink to the system installed LLD).
r? @alexcrichton
|
|
|
|
|
|
|
|
|
|
Do not generate assumes for plain integer casts
I gave up on making anything more elegant for now.
r? @eddyb
|
|
this field defaults to the LD / GNU flavor
|
|
This commit adds the necessary definitions for target specs and such as well as
the necessary support in libstd to compile basic `aarch64-pc-windows-msvc`
binaries. The target is not currently built on CI, but it can be built locally
with:
./configure --target=aarch64-pc-windows-msvc --set rust.lld
./x.py build src/libstd --target aarch64-pc-windows-msvc
Currently this fails to build `libtest` due to a linker bug (seemingly in LLD?)
which hasn't been investigate yet. Otherwise though with libstd you can build a
hello world program (linked with LLD). I've not tried to execute it yet, but it
at least links!
Full support for this target is still a long road ahead, but this is hopefully a
good stepping stone to get started.
Points of note about this target are:
* Currently defaults to `panic=abort` as support is still landing in LLVM for
SEH on AArch64.
* Currently defaults to LLD as a linker as I was able to get farther with it
than I was with `link.exe`
|
|
A few cleanups
- change `skip(1).next()` to `nth(1)`
- collapse some `if-else` expressions
- remove a few explicit `return`s
- remove an unnecessary field name
- dereference once instead of matching on multiple references
- prefer `iter().enumerate()` to indexing with `for`
- remove some unnecessary lifetime annotations
- use `writeln!()` instead of `write!()`+`\n`
- remove redundant parentheses
- shorten some enum variant names
- a few other cleanups suggested by `clippy`
|
|
targets: aarch64: Add bare-metal aarch64 target
A generic AArch64 target that can be used for writing bare-metal code
for 64-bit ARM architectures.
|
|
jakllsch:netbsd-ad22a005-b917-47f3-8156-f717d36f6bbe, r=estebank
Add aarch64-unknown-netbsd target
Depends on #53116.
|
