about summary refs log tree commit diff
path: root/src/test/run-make
AgeCommit message (Collapse)AuthorLines
2021-03-28test: run-make: skip tests on unsupported platformsTom Eccles-0/+7
The tests issue-36710 and incr-prev-body-beyond-eof were changed in a previous commit so that the correct target was passed to rustc (previously rustc was building for the host not for the specific target). Since that change it turns out that these platforms never worked (they only appeared to work because rustc was actually building for the host architecture). The wasm architectures fall over trying to build the C++ file in issue-36710. They look for clang (which isn't installed in the test-various docker container). If clang is installed, they can't find a wasm c++ standard library to link to. nvtptx64-nvidia-cuda fails in rustc saying it can't find std. The rust platforms support page says that std is supported on cuda so this is surprising. dist-i586-gnu-i586-i686-musl can't find the C++ compiler. There is only a musl-gcc and no musl-g++ in /musl-i586/bin/. The Docker image probably needs tweaking.
2021-03-28test: run-make: flag tests which won't work in no-std environmentsTom Eccles-0/+5
2021-03-28run-make: skip issue-36710 on riscv64 and armhfTom Eccles-0/+4
The test assumes it can run target binaries on the host. This not true for riscv64 CI (or for other platforms using remote-test-server).
2021-03-28run-make: Specify --target to rustcTom Eccles-14/+5
Resolves #78911 The target's linker was used but rustc wasn't told to build for that target (instead defaulting to the host). This led to the host instead of the target getting tested and to the linker getting inappropriate arguments.
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
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-26 21:56:25 +0000