| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #71610 (InvalidUndefBytes: Track size of undef region used)
- #72161 (Replace fcntl-based file lock with flock)
- #72306 (Break tokens before checking if they are 'probably equal')
- #72325 (Always generated object code for `#![no_builtins]`)
Failed merges:
r? @ghost
|
|
Always generated object code for `#![no_builtins]`
This commit updates the code generation for `#![no_builtins]` to always
produce object files instead of conditionally respecting
`-Clinker-plugin-lto` and sometimes producing bitcode. This is intended
to address rust-lang/cargo#8239.
The issue at hand here is that Cargo has tried to get "smarter" about
codegen in whole crate graph scenarios. When LTO is enabled it attempts
to avoid codegen on as many crates as possible, opting to pass
`-Clinker-plugin-lto` where it can to only generate bitcode. When this
is combined with `-Zbuild-std`, however, it means that
`compiler-builtins` only generates LLVM bitcode instead of object files.
Rustc's own LTO passes then explicitly skip `compiler-builtins` (because
it wouldn't work anyway) which means that LLVM bitcode gets sent to the
linker, which chokes most of the time.
The fix in this PR is to not actually respect `-Clinker-plugin-lto` for
`#![no_builtins]` crates. These crates, even if slurped up by the linker
rather than rustc, will not work with LTO. They define symbols which are
only referenced as part of codegen, so LTO's aggressive internalization
would trivially remove the symbols only to have the linker realize later
that the symbol is undefined. Since pure-bitcode never makes sense for
these libraries, the `-Clinker-plugin-lto` flag is silently ignored.
|
|
Some renaming and minor refactoring for `NativeLibraryKind`
|
|
Add target thumbv7a-uwp-windows-msvc
Add target spec for thumbv7a-uwp-windows-msvc, so that libraries written in Rust will have a chance to run on ARM-based devices with Windows 10.
So far I managed to create a proof-of-concept library for Universal Windows Platform apps to consume and it worked on a Windows Phone. However, building a standalone executable seemed troublesome due to `LLVM ERROR: target does not implement codeview register mapping` stuff (see also https://github.com/rust-lang/rust/issues/52659#issuecomment-408233322 ).
Steps to test:
1. Clone and build this version
```sh
git clone https://github.com/bdbai/rust.git
cd rust
python x.py build -i --target thumbv7a-uwp-windows-msvc --stage 1 src/libstd
rustup toolchain link arm-uwp-stage1 .\build\x86_64-pc-windows-msvc\stage1\
```
2. Create a new library crate
```sh
cargo new --lib arm-uwp-test
cd arm-uwp-test
```
3. Change `crate-type` in `Cargo.toml` to `staticlib`
```toml
[lib]
crate-type=["staticlib"]
```
4. Replace the following code in `src/lib.rs`
```rust
#[no_mangle]
pub extern "system" fn call_rust() -> i32 {
2333
}
```
5. Build the crate
```sh
cargo +arm-uwp-stage1 build -v --target thumbv7a-uwp-windows-msvc
```
6. `arm-uwp-test.lib` should appear in `target\thumbv7a-uwp-windows-msvc\debug`
To consume this library:
1. Make sure Visual Studio 2017 and Windows 10 SDK (10.0.17134 or above) are installed
2. Create a new Blank App (C++/WinRT) in Visual Studio 2017 (Visual Studio 2019 cannot deploy UWP apps to Windows Phone)
3. Go to Property Pages, and then Linker->Input->Additional Dependencies, add `arm-uwp-test.lib` produced just now
4. Manually declare function prototypes in `MainPage.h`
```c++
extern "C" {
int call_rust();
}
```
5. Replace the `ClickHandler` part in `MainPage.cpp`
```c++
myButton().Content(box_value(std::to_wstring(call_rust())));
```
6. Build and deploy this app to an ARM device running Windows 10. The app should run and show `2333` when the button is clicked.
|
|
Suggest installing VS Build Tools in more situations
When MSVC's `link.exe` wasn't found but another `link.exe` was, the error message given can be [impenetrable](https://pastebin.com/MRMCr7HM) to many users. The usual suspect is GNU's `link` tool. In this case, inform the user that they may need to install VS build tools.
This only applies when Microsoft's link tool is expected.
|
|
Dumb NRVO
This is a very simple version of an NRVO pass, which scans backwards from the `return` terminator to see if there is an an assignment like `_0 = _1`. If a basic block with two or more predecessors is encountered during this scan without first seeing an assignment to the return place, we bail out. This avoids running a full "reaching definitions" dataflow analysis.
I wanted to see how much `rustc` would benefit from even a very limited version of this optimization. We should be able to use this as a point of comparison for more advanced versions that are based on live ranges.
r? @ghost
|
|
|
|
NativeLibrary(Kind) -> NativeLib(Kind)
NativeStatic -> StaticBundle
NativeStaticNobundle -> StaticNoBundle
NativeFramework -> Framework
NativeRawDylib -> RawDylib
NativeUnknown -> Unspecified
|
|
|
|
|
|
When MSVC's `link.exe` wasn't found but another `link.exe` was, the error message given can be impenetrable to many users. The usual suspect is GNU's `link` tool. In this case, inform the user that they may need to install VS build tools.
This only applies when Microsoft's link tool is expected. Not `lld-link` or other MSVC compatible linkers.
|
|
linker: More systematic handling of CRT objects
Document which kinds of `crt0.o`-like objects we link and in which cases, discovering bugs in process.
`src/librustc_target/spec/crt_objects.rs` is the place to start reading from.
This PR also automatically contains half of the `-static-pie` support (https://github.com/rust-lang/rust/pull/70740), because that's one of the six cases that we need to consider when linking CRT objects.
This is a breaking change for custom target specifications that specify CRT objects.
Closes https://github.com/rust-lang/rust/issues/30868
|
|
This commit updates the code generation for `#![no_builtins]` to always
produce object files instead of conditionally respecting
`-Clinker-plugin-lto` and sometimes producing bitcode. This is intended
to address rust-lang/cargo#8239.
The issue at hand here is that Cargo has tried to get "smarter" about
codegen in whole crate graph scenarios. When LTO is enabled it attempts
to avoid codegen on as many crates as possible, opting to pass
`-Clinker-plugin-lto` where it can to only generate bitcode. When this
is combined with `-Zbuild-std`, however, it means that
`compiler-builtins` only generates LLVM bitcode instead of object files.
Rustc's own LTO passes then explicitly skip `compiler-builtins` (because
it wouldn't work anyway) which means that LLVM bitcode gets sent to the
linker, which chokes most of the time.
The fix in this PR is to not actually respect `-Clinker-plugin-lto` for
`#![no_builtins]` crates. These crates, even if slurped up by the linker
rather than rustc, will not work with LTO. They define symbols which are
only referenced as part of codegen, so LTO's aggressive internalization
would trivially remove the symbols only to have the linker realize later
that the symbol is undefined. Since pure-bitcode never makes sense for
these libraries, the `-Clinker-plugin-lto` flag is silently ignored.
|
|
|
|
|
|
|
|
|
|
Don't pass --dynamic-linker for Fuchsia dylibs
This was causing a PT_INTERP header in Fuchsia dylibs (implying that
they're executable when they're not).
r? @Mark-Simulacrum
cc @frobtech @petrhosek
|
|
|
|
Consistently use LLVM lifetime markers during codegen
Ensure that inliner inserts lifetime markers if they have been emitted during
codegen. Otherwise if allocas from inlined functions are merged together,
lifetime markers from one function might invalidate load & stores performed
by the other one.
Fixes #72154.
|
|
Add built in PSP target
This adds a new target, `mipsel-sony-psp`, corresponding to the Sony PSP. The linker script is necessary to handle special sections, which are required by the target. This has been tested with my [rust-psp] crate and I can confirm it works as intended.
The linker script is taken from [here]. It has been slightly adapted to work with rust and LLD.
The `stdarch` submodule was also updated in order for `libcore` to build successfully.
[rust-psp]: https://github.com/overdrivenpotato/rust-psp
[here]: https://github.com/pspdev/pspsdk/blob/master/src/base/linkfile.prx.in
|
|
This was causing a PT_INTERP header in Fuchsia dylibs (implying that
they're executable when they're not).
|
|
r=alexcrichton
Change `WorkProduct::saved_files` to an `Option`.
Because there is at most one file.
r? @bjorn3
|
|
Ensure that inliner inserts lifetime markers if they have been emitted during
codegen. Otherwise if allocas from inlined functions are merged together,
lifetime markers from one function might invalidate load & stores performed
by the other one.
|
|
|
|
|
|
Because there is at most one file.
|
|
|
|
|
|
|
|
add codegen option strip
closes https://github.com/rust-lang/rust/issues/71757
I don't know if the flags added here works for all linkers. I only tested on my Linux pc. I also don't know what is the best for emlinker, PtxLinker, MsvcLinker. The option for WasmLd is copied from https://aransentin.github.io/cwasm/.
|
|
|
|
move strip option to "Z"
add more strip options, remove strip-debuginfo-if-disabled
merge strip and debuginfo
|
|
Fix disagreeement about CGU reuse and LTO
This commit fixes an issue where the codegen backend's selection of LTO
disagreed with what the codegen later thought was being done. Discovered
in #72006 we have a longstanding issue where if `-Clinker-plugin-lto` in
optimized mode is compiled incrementally it will always panic on the
second compilation. The underlying issue turned out to be that the
production of the original artifact determined that LTO should not be
done (because it's being postponed to the linker) but the CGU reuse
selection thought that LTO was done so it was trying to load pre-LTO
artifacts which were never generated.
The fix here is to ensure that the logic when generating code which
determines what kind of LTO is being done is shared amongst the CGU
reuse decision and the backend actually doing LTO. This means that
they'll both be in agreement about whether the previous compilation did
indeed produce incremental pre-LTO artifacts.
Closes #72006
|
|
This commit fixes an issue where the codegen backend's selection of LTO
disagreed with what the codegen later thought was being done. Discovered
in #72006 we have a longstanding issue where if `-Clinker-plugin-lto` in
optimized mode is compiled incrementally it will always panic on the
second compilation. The underlying issue turned out to be that the
production of the original artifact determined that LTO should not be
done (because it's being postponed to the linker) but the CGU reuse
selection thought that LTO was done so it was trying to load pre-LTO
artifacts which were never generated.
The fix here is to ensure that the logic when generating code which
determines what kind of LTO is being done is shared amongst the CGU
reuse decision and the backend actually doing LTO. This means that
they'll both be in agreement about whether the previous compilation did
indeed produce incremental pre-LTO artifacts.
Closes #72006
|
|
Remove ast::{Ident, Name} reexports.
The reexport of `Symbol` into `Name` confused me.
|
|
Simplify the `tcx.alloc_map` API
This PR changes all functions that require manually locking the `alloc_map` to functions on `TyCtxt` that lock the map internally. In the same step we make the `TyCtxt::alloc_map` field private.
r? @RalfJung
|
|
Improve bitcode generation for Apple platforms
Some improvements for iOS bitcode support suggested by Alex over at https://github.com/getditto/rust-bitcode/issues/9. r? @alexcrichton
This improves Rust's bitcode generation so that provided you have a compatible LLVM version, Rust targeting iOS should work out of the box when compiled into bitcode-enabled apps, and when submitted to the App Store. I've tested these changes using Xcode 11.4.1 and Apple's vendored LLVM, [tag `swift-5.2.3-RELEASE`](https://github.com/apple/llvm-project/releases/tag/swift-5.2.3-RELEASE).
1. Force `aarch64-apple-ios` and `aarch64-apple-tvos` targets to always emit full bitcode sections, even when cargo is trying to optimise by invoking `rustc` with `-Cembed-bitcode=no`. Since Apple recommends bitcode on iOS and requires it on tvOS it is likely that this is what developers intend. Currently you need to override the codegen options with `RUSTFLAGS`, which is far from obvious.
2. Provide an LLVM cmdline in the target spec. Apple's bitcode verification process looks for some arguments. For Rust modules to be accepted we must pretend they were produced similarly. A suitable default is provided in `TargetOptions` for iOS, copied directly from the a clang equivalent section.
In the context of Apple platforms, the predominant purpose of bitcode is App Store submissions, so simulator and 32-bit targets are not relevant. I'm hoping that the cmdline strings will not be a maintenance burden to keep up-to-date. If the event of any future incompatibilities, hopefully a custom target config would offer enough flexibility to work around it. It's impossible to say for sure.
Due to unrelated build errors I haven't been able to build and test a full tvOS toolchain. I've stopped short of providing a similar `bitcode_llvm_cmdline` until I can actually test it.
|
|
|
|
|
|
|
|
The App Store performs certain sanity checks on bitcode, including that
an acceptable set of command line arguments was used when compiling a
given module. For Rust code to be distributed on the app store with
bitcode rustc must pretend to have the same command line arguments.
|
|
At this time Apple recommends Bitcode be included for iOS apps, and
requires it for tvOS. It is unlikely that a developer would want to
disable bitcode when building for these targets, yet by default it will
not be generated. This presents a papercut for developers on those
platforms.
Introduces a new TargetOption boolean key for specific triples to
indicate that bitcode should be generated, even if cargo attempts to
optimise with -Cembed-bitcode=no.
|
|
Define UB in float-to-int casts to saturate
This closes #10184 by defining the behavior there to saturate infinities and values exceeding the integral range (on the lower or upper end). `NaN` is sent to zero.
|
|
- Round to zero, and representable values cast directly.
- `NaN` goes to 0
- Values beyond the limits of the type are saturated to the "nearest value"
(essentially rounding to zero, in some sense) in the integral type, so e.g.
`f32::INFINITY` would go to `{u,i}N::MAX.`
|
|
Don't copy bytecode files into the incr. comp. cache.
It's no longer necessary now that bitcode is embedded into object files.
This change meant that `WorkProductFileKind::Bytecode` is no longer
necessary, which means that type is no longer necessary, which allowed
several places in the code to become simpler.
This commit was written by @nnethercote in https://github.com/rust-lang/rust/pull/70458 but that didn't land. In the meantime though we managed to land it in https://github.com/rust-lang/rust/pull/71528 and that doesn't seem to be causing too many fires, so I'm re-sending this patch!
|
|
...emulating `MutatingUseContext::Call`
|
|
fix rustdoc warnings
|
|
cleanup: `config::CrateType` -> `CrateType`
|
