| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Might be subject to the birthday paradox occasionally, causing spurious failures.
Addresses: https://github.com/rust-lang/rust/pull/70740#pullrequestreview-430981320
|
|
macros
|
|
Print environment variables accessed by rustc as special comments into depinfo files
So cargo (and perhaps others tools) can use them for linting (at least) or for actually rebuilding crates on env var changes.
---
I've recently observed one more forgotten environment variable in a build script https://github.com/rust-lang/rust/pull/71314/commits/8a77d1ca3fc2df789157f7986ddbaf2a377ff0fe and thought it would be nice to provide the list of accessed variables to cargo automatically as a part of depinfo.
Unsurprisingly, I wasn't the first who had this idea - cc https://github.com/rust-lang/rust/issues/70517 https://github.com/rust-lang/rust/issues/40364 https://github.com/rust-lang/rust/issues/44074.
Also, there are dozens of uses of `(option_)env!` in rustc repo and, like, half of them are not registered in build scripts.
---
Description:
- depinfo files are extended with special comments containing info about environment variables accessed during compilation.
- Comment format for environment variables with successfully retrieved value: `# env-dep:KEY=VALUE`.
- Comment format for environment variables without successfully retrieved value: `# env-dep:KEY` (can happen with `option_env!`).
- `KEY` and `VALUE` are minimally escaped (`\n`, `\r`, `\\`) so they don't break makefile comments and can be unescaped by anything that can unescape standard `escape_default` and friends.
FCP report: https://github.com/rust-lang/rust/pull/71858#issuecomment-633071488
Closes https://github.com/rust-lang/rust/issues/70517
Closes https://github.com/rust-lang/rust/issues/40364
Closes https://github.com/rust-lang/rust/issues/44074
A new issue in the cargo repo will be needed to track the cargo side of this feature.
r? @ehuss
|
|
Fixes: https://github.com/rust-lang/rust/issues/70693
|
|
|
|
|
|
Change opt-level from 2 back to 3
In Cargo.toml, the opt-level for `release` and `bench` was overridden to be 2. This was to work around a problem with LLVM 7. However, rust no longer uses LLVM 7, so this is hopefully no longer needed?
I tried a little bit to replicate the original problem, and could not. I think running this through CI is the best way to smoke test this :) Even if things break dramatically, the comment should be updated to reflect that things are still broken with LLVM 9.
I'm just getting started playing with the compiler, so apologies if I've missed an obvious problem here.
fixes #52378
(possibly relevant is the [current update to LLVM 10](https://github.com/rust-lang/rust/pull/67759))
|
|
In Cargo.toml, the opt-level for `release` and `bench` was
overridden to be 2. This was to work around a problem with LLVM
7. However, rust no longer uses LLVM 7, so this is no longer
needed.
This creates a small compile time regression in MIR constant eval,
so I've added a #[inline(always)] on the `step` function used in
const eval
Also creates a binary size increase in wasm-stringify-ints-small,
so I've bumped the limit there.
|
|
|
|
|
|
This fixes a linkage issue that was fixed a while ago, and adds thumbv8
support.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The WebAssembly targets of rustc have weird issues around name mangling
and import the same name from different modules. This all largely stems
from the fact that we're using literal symbol names in LLVM IR to
represent what a function is called when it's imported, and we're not
using the wasm-specific `wasm-import-name` attribute. This in turn leads
to two issues:
* If, in the same codegen unit, the same FFI symbol is referenced twice
then rustc, when translating to LLVM IR, will only reference one
symbol from the first wasm module referenced.
* There's also a bug in LLD [1] where even if two codegen units
reference different modules, having the same symbol names means that
LLD coalesces the symbols and only refers to one wasm module.
Put another way, all our imported wasm symbols from the environment are
keyed off their LLVM IR symbol name, which has lots of collisions today.
This commit fixes the issue by implementing two changes:
1. All wasm symbols with `#[link(wasm_import_module = "...")]` are
mangled by default in LLVM IR. This means they're all given unique names.
2. Symbols then use the `wasm-import-name` attribute to ensure that the
WebAssembly file uses the correct import name.
When put together this should ensure we don't trip over the LLD bug [1]
and we also codegen IR correctly always referencing the right symbols
with the right import module/name pairs.
Closes #50021
Closes #56309
Closes #63562
[1]: https://bugs.llvm.org/show_bug.cgi?id=44316
|
|
- Compatible with Emscripten 1.38.46-upstream or later upstream.
- Refactors the Emscripten target spec to share code with other wasm
targets.
- Replaces the old incorrect wasm32 C call ABI with the correct one,
preserving the old one as wasm32_bindgen_compat for wasm-bindgen
compatibility.
- Updates the varargs ABI used by Emscripten and deletes the old one.
- Removes the obsolete wasm32-experimental-emscripten target.
- Uses EMCC_CFLAGS on CI to avoid the timeout problems with #63649.
|
|
r=alexcrichton"
This reverts commit 7870050796e5904a0fc85ecbe6fa6dde1cfe0c91, reversing
changes made to 2e7244807a7878f6eca3eb7d97ae9b413aa49014.
|
|
|
|
|
|
|
|
Currently when linking an artifact rustc will only conditionally call
the `Linker::export_symbols` function, but this causes issues on some
targets, like WebAssembly, where it means that executable outputs will
not have the same symbols exported that cdylib outputs have. This commit
sinks the conditional call to `export_symbols` inside the various
implementations of the function that still need it, and otherwise the
wasm linker is configured to always pass through symbol visibility
lists.
|
|
|
|
Cut down on number formating code size
r? @alexcrichton
|
|
This makes the tests easier to read, and makes it possible to tell which
tests aren't being run on the host platform.
Fixes #56704.
|
|
|
|
Removes some unsafe *and* saves almost half a kilobyte of code size.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
add test for issue #21335
Running this test with LLVM assertions enabled doesn't seem to trigger an assertion on my Mac.
Fixes #21335.
|
|
|
|
|
|
|
|
Fixes #21335.
|
|
|
|
[CI] Run a `thumbv7m-none-eabi` binary using `qemu-system-arm` [IRR-2018-embedded]
## What's included?
- Run a `thumbv7m-none-eabi` binary using `qemu-system-arm`
- We are using `cortex-m-rt = "=0.5.4"` which does not use `proc_macro`.
(reason: stage2 build of rustc does not work well with `proc_macro` in `run-make` phase.)
- We are using GNU LD for now.
## Blocker
All resolved.
- ~[Waiting] `#[panic_handler]` is not available in stable.~
- [Merged] https://github.com/rust-lang/rust/pull/53619
- ~[Waiting] https://github.com/japaric/lm3s6965evb: does not compile on stable.~
- [OK] dependent crate ~`panic-abort`~ `panic-halt`: already moved to use `#[panic_handler]`.
## Update
`#[panic_handler]` will be stabilized in Rust 1.30.
CC @kennytm @jamesmunns @nerdyvaishali
|
|
Fix tracking issue numbers for some unstable features
And also remove deprecated unstable `#[panic_implementation]` attribute that was superseded by stable `#[panic_handler]` and doesn't have an open tracking issue.
|
|
|
|
It was superseded by `#[panic_handler]`
|
|
Some code in the TLS implementation in libstd stores `Some(val)` into an
`&mut Option<T>` (effectively) and then pulls out `&T`, but it currently
uses `.unwrap()` which can codegen into a panic even though it can never
panic. With sufficient optimizations enabled (like LTO) the compiler can
see through this but this commit helps it along in normal mode
(`--release` with Cargo by default) to avoid codegen'ing the panic path.
This ends up improving the optimized codegen on wasm by ensuring that a
call to panic pulling in more file size doesn't stick around.
|
|
This reverts commit 3cc8f738d4247a9b475d8e074b621e602ac2b7be.
|
|
The issue of passing around SIMD types as values between functions has
seen [quite a lot] of [discussion], and although we thought [we fixed
it][quite a lot] it [wasn't]! This PR is a change to rustc to, again,
try to fix this issue.
The fundamental problem here remains the same, if a SIMD vector argument
is passed by-value in LLVM's function type, then if the caller and
callee disagree on target features a miscompile happens. We solve this
by never passing SIMD vectors by-value, but LLVM will still thwart us
with its argument promotion pass to promote by-ref SIMD arguments to
by-val SIMD arguments.
This commit is an attempt to thwart LLVM thwarting us. We, just before
codegen, will take yet another look at the LLVM module and demote any
by-value SIMD arguments we see. This is a very manual attempt by us to
ensure the codegen for a module keeps working, and it unfortunately is
likely producing suboptimal code, even in release mode. The saving grace
for this, in theory, is that if SIMD types are passed by-value across
a boundary in release mode it's pretty unlikely to be performance
sensitive (as it's already doing a load/store, and otherwise
perf-sensitive bits should be inlined).
The implementation here is basically a big wad of C++. It was largely
copied from LLVM's own argument promotion pass, only doing the reverse.
In local testing this...
Closes #50154
Closes #52636
Closes #54583
Closes #55059
[quite a lot]: https://github.com/rust-lang/rust/pull/47743
[discussion]: https://github.com/rust-lang/rust/issues/44367
[wasn't]: https://github.com/rust-lang/rust/issues/50154
|
|
|
