about summary refs log tree commit diff
path: root/src/test/run-make
AgeCommit message (Collapse)AuthorLines
2021-03-22only run RemoveZsts at mir-opt-level 3 and aboveErik Desjardins-0/+1
2021-03-15Rollup merge of #83132 - Aaron1011:fix/incr-cache-dummy, r=estebankDylan DPC-0/+26
Don't encode file information for span with a dummy location Fixes #83112 The location information for a dummy span isn't real, so don't encode it. This brings the incr comp cache code into line with the Span `StableHash` impl, which doesn't hash the location information for dummy spans. Previously, we would attempt to load the 'original' file from a dummy span - if the file id changed (e.g. due to being moved on disk), we would get an ICE, since the Span was still valid due to its hash being unchanged.
2021-03-14Don't encode file information for span with a dummy locationAaron Hill-0/+26
Fixes #83112 The location information for a dummy span isn't real, so don't encode it. This brings the incr comp cache code into line with the Span `StableHash` impl, which doesn't hash the location information for dummy spans. Previously, we would attempt to load the 'original' file from a dummy span - if the file id changed (e.g. due to being moved on disk), we would get an ICE, since the Span was still valid due to its hash being unchanged.
2021-03-13Do not emit alloca for ZST local even if it is uninitializedSimon Vandel Sillesen-1/+0
2021-02-28Remove storage markers if they won't be used during code generationTomasz Miąsko-2/+0
The storage markers constitute a substantial portion of all MIR statements. At the same time, for builds without any optimizations, the storage markers have no further use during and after MIR optimization phase. If storage markers are not necessary for code generation, remove them.
2021-02-17[libtest] Run the test synchronously when hitting thread limithyd-dev-0/+23
2021-01-13Update tests for extern block lintingMark Rousskov-4/+6
2021-01-11--emit=mir now emits both `mir_for_ctfe` and `optimized_mir` for `const fn`oli-0/+65
2020-11-29Auto merge of #78122 - fusion-engineering-forks:fmt-write-bounds-check, ↵bors-0/+57
r=Mark-Simulacrum Avoid panic_bounds_check in fmt::write. Writing any fmt::Arguments would trigger the inclusion of usize formatting and padding code in the resulting binary, because indexing used in fmt::write would generate code using panic_bounds_check, which prints the index and length. These bounds checks are not necessary, as fmt::Arguments never contains any out-of-bounds indexes. This change replaces them with unsafe get_unchecked, to reduce the amount of generated code, which is especially important for embedded targets. --- Demonstration of the size of and the symbols in a 'hello world' no_std binary: <details> <summary>Source code</summary> ```rust #![feature(lang_items)] #![feature(start)] #![no_std] use core::fmt; use core::fmt::Write; #[link(name = "c")] extern "C" { #[allow(improper_ctypes)] fn write(fd: i32, s: &str) -> isize; fn exit(code: i32) -> !; } struct Stdout; impl fmt::Write for Stdout { fn write_str(&mut self, s: &str) -> fmt::Result { unsafe { write(1, s) }; Ok(()) } } #[start] fn main(_argc: isize, _argv: *const *const u8) -> isize { let _ = writeln!(Stdout, "Hello World"); 0 } #[lang = "eh_personality"] fn eh_personality() {} #[panic_handler] fn panic(_: &core::panic::PanicInfo) -> ! { unsafe { exit(1) }; } ``` </details> Before: ``` text data bss dec hex filename 6059 736 8 6803 1a93 before ``` ``` 0000000000001e00 T <T as core::any::Any>::type_id 0000000000003dd0 D core::fmt::num::DEC_DIGITS_LUT 0000000000001ce0 T core::fmt::num::imp::<impl core::fmt::Display for u64>::fmt 0000000000001ce0 T core::fmt::num::imp::<impl core::fmt::Display for usize>::fmt 0000000000001370 T core::fmt::write 0000000000001b30 t core::fmt::Formatter::pad_integral::write_prefix 0000000000001660 T core::fmt::Formatter::pad_integral 0000000000001350 T core::ops::function::FnOnce::call_once 0000000000001b80 t core::ptr::drop_in_place 0000000000001120 t core::ptr::drop_in_place 0000000000001c50 t core::iter::adapters::zip::Zip<A,B>::new 0000000000001c90 t core::iter::adapters::zip::Zip<A,B>::new 0000000000001b90 T core::panicking::panic_bounds_check 0000000000001c10 T core::panicking::panic_fmt 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ``` After: ``` text data bss dec hex filename 3068 600 8 3676 e5c after ``` ``` 0000000000001360 T core::fmt::write 0000000000001340 T core::ops::function::FnOnce::call_once 0000000000001120 t core::ptr::drop_in_place 0000000000001620 t core::iter::adapters::zip::Zip<A,B>::new 0000000000001660 t core::iter::adapters::zip::Zip<A,B>::new 0000000000001130 t <&mut W as core::fmt::Write>::write_char 0000000000001200 t <&mut W as core::fmt::Write>::write_fmt 0000000000001250 t <&mut W as core::fmt::Write>::write_str ```
2020-11-29Add test to check for fmt::write bloat.Mara Bos-0/+57
It checks that fmt::write by itself doesn't pull in any panicking or or display code.
2020-11-12Auto merge of #76256 - tgnottingham:issue-74890, r=nikomatsakisbors-0/+48
incr-comp: hash and serialize span end line/column Hash both the length and the end location (line/column) of a span. If we hash only the length, for example, then two otherwise equal spans with different end locations will have the same hash. This can cause a problem during incremental compilation wherein a previous result for a query that depends on the end location of a span will be incorrectly reused when the end location of the span it depends on has changed. A similar analysis applies if some query depends specifically on the length of the span, but we only hash the end location. So hash both. Fix #46744, fix #59954, fix #63161, fix #73640, fix #73967, fix #74890, fix #75900 --- See #74890 for a more in-depth analysis. I haven't thought about what other problems this root cause could be responsible for. Please let me know if anything springs to mind. I believe the issue has existed since the inception of incremental compilation.
2020-11-09incr-comp: add ignore-32bit directive to incr-prev-body-beyond-eof testTyson Nottingham-1/+5
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
2020-11-08incr-comp: add clarifying comments to incr-prev-body-beyond-eof testTyson Nottingham-4/+8
2020-11-06fix shellcheck error of SC2148Daiki Ihara-0/+2
2020-11-04incr-comp: hash span end line/columnTyson Nottingham-0/+40
Hash both the length and the end location (line/column) of a span. If we hash only the length, for example, then two otherwise equal spans with different end locations will have the same hash. This can cause a problem during incremental compilation wherein a previous result for a query that depends on the end location of a span will be incorrectly reused when the end location of the span it depends on has changed. A similar analysis applies if some query depends specifically on the length of the span, but we only hash the end location. So hash both. Fix #46744, fix #59954, fix #63161, fix #73640, fix #73967, fix #74890, fix #75900
2020-10-19Ignore on 32-bit targetsJonas Schievink-2/+1
2020-10-19ignore-thumbJonas Schievink-0/+1
2020-10-19Ignore test on WASMJonas Schievink-0/+2
2020-10-19Move issue-36710 test to run-makeJonas Schievink-0/+36
Somewhat hacky to reuse `tools.mk` like this, we should probably migrate most of them now
2020-09-25cleaning up codeRaoul Strackx-26/+35
2020-09-25Building libunwind with new CMakeLists.Raoul Strackx-8/+3
The old CMakeLists file of libunwind used the C compiler to compile assembly files. This caused such code not to be hardened.
2020-09-25Adding checks for module level assemblyRaoul Strackx-9/+115
2020-09-25LVI hardening tests for cmakeRaoul Strackx-0/+120
2020-09-25testing c++ code (cc crate)Raoul Strackx-0/+55
2020-09-25test hardening C inline assembly code (cc crate)Raoul Strackx-1/+33
2020-09-25started using cc crateRaoul Strackx-4/+29
2020-09-25LVI test std libRaoul Strackx-16/+78
2020-09-25Adding checks for assembly files in libunwindRaoul Strackx-0/+37
2020-09-20Provide bootstrap tools with RUSTC in environmentMark Rousskov-3/+3
2020-07-26proc_macro: Add API for tracked access to environment variablesVadim Petrochenkov-0/+29
2020-07-13Fix src/test/run-make/static-pie/test-aslr.rsHarald Hoyer-1/+1
Might be subject to the birthday paradox occasionally, causing spurious failures. Addresses: https://github.com/rust-lang/rust/pull/70740#pullrequestreview-430981320
2020-07-01expand: Stop using nonterminals for passing tokens to attribute and derive ↵Vadim Petrochenkov-1/+1
macros
2020-06-25Auto merge of #71858 - petrochenkov:env, r=Mark-Simulacrumbors-0/+14
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
2020-06-15Enable static-pie for the x86_64-unknown-linux-musl targetHarald Hoyer-0/+58
Fixes: https://github.com/rust-lang/rust/issues/70693
2020-05-31Print accessed env vars as special comments into depinfo filesVadim Petrochenkov-0/+14
2020-04-26Use Cell::take in a couple placesThinkChaos-1/+1
2020-01-31Auto merge of #67878 - Others:opt-3, r=Mark-Simulacrumbors-1/+1
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))
2020-01-30Change opt-level from 2 back to 3Gregor Peach-1/+1
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.
2020-01-21Do not use Cortex-M0 since Qemu is too oldJonas Schievink-1/+2
2020-01-21Check in lockfileJonas Schievink-0/+199
2020-01-21Update dependenciesJonas Schievink-8/+4
This fixes a linkage issue that was fixed a while ago, and adds thumbv8 support.
2020-01-21Use the right runners for all thumb targetsJonas Schievink-6/+19
2020-01-21Fix thumb target CIJonas Schievink-7/+4
2020-01-08Check for the entry kindmaik-3/+3
2020-01-08Remove unnecessary global countingmaik-11/+5
2020-01-07Fix indentationMaik Klein-1/+1
2020-01-07Add tests for static variablesMaik Klein-7/+20
2019-12-16Fix handling of wasm import modules and namesAlex Crichton-0/+154
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
2019-10-16Upgrade Emscripten targets to use upstream LLVM backendThomas Lively-7/+7
- 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.
2019-10-05Revert "Auto merge of #63649 - tlively:emscripten-upstream-upgrade, ↵Tyler Mandry-7/+7
r=alexcrichton" This reverts commit 7870050796e5904a0fc85ecbe6fa6dde1cfe0c91, reversing changes made to 2e7244807a7878f6eca3eb7d97ae9b413aa49014.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 23:29:18 +0000