summary refs log tree commit diff
path: root/src/test/run-make
AgeCommit message (Collapse)AuthorLines
2021-04-08rustc: Add a new `wasm` ABIAlex Crichton-0/+116
This commit implements the idea of a new ABI for the WebAssembly target, one called `"wasm"`. This ABI is entirely of my own invention and has no current precedent, but I think that the addition of this ABI might help solve a number of issues with the WebAssembly targets. When `wasm32-unknown-unknown` was first added to Rust I naively "implemented an abi" for the target. I then went to write `wasm-bindgen` which accidentally relied on details of this ABI. Turns out the ABI definition didn't match C, which is causing issues for C/Rust interop. Currently the compiler has a "wasm32 bindgen compat" ABI which is the original implementation I added, and it's purely there for, well, `wasm-bindgen`. Another issue with the WebAssembly target is that it's not clear to me when and if the default C ABI will change to account for WebAssembly's multi-value feature (a feature that allows functions to return multiple values). Even if this does happen, though, it seems like the C ABI will be guided based on the performance of WebAssembly code and will likely not match even what the current wasm-bindgen-compat ABI is today. This leaves a hole in Rust's expressivity in binding WebAssembly where given a particular import type, Rust may not be able to import that signature with an updated C ABI for multi-value. To fix these issues I had the idea of a new ABI for WebAssembly, one called `wasm`. The definition of this ABI is "what you write maps straight to wasm". The goal here is that whatever you write down in the parameter list or in the return values goes straight into the function's signature in the WebAssembly file. This special ABI is for intentionally matching the ABI of an imported function from the environment or exporting a function with the right signature. With the addition of a new ABI, this enables rustc to: * Eventually remove the "wasm-bindgen compat hack". Once this ABI is stable wasm-bindgen can switch to using it everywhere. Afterwards the wasm32-unknown-unknown target can have its default ABI updated to match C. * Expose the ability to precisely match an ABI signature for a WebAssembly function, regardless of what the C ABI that clang chooses turns out to be. * Continue to evolve the definition of the default C ABI to match what clang does on all targets, since the purpose of that ABI will be explicitly matching C rather than generating particular function imports/exports. Naturally this is implemented as an unstable feature initially, but it would be nice for this to get stabilized (if it works) in the near-ish future to remove the wasm32-unknown-unknown incompatibility with the C ABI. Doing this, however, requires the feature to be on stable because wasm-bindgen works with stable Rust.
2021-04-06Fix handling of `--output-format json` flagJoshua Nelson-0/+10
- Don't treat it as deprecated on stable and beta channels. Before, it would give confusing and incorrect output: ``` warning: the 'output-format' flag is considered deprecated | = warning: see issue #44136 <https://github.com/rust-lang/rust/issues/44136> for more information error: json output format isn't supported for doc generation ``` Both of those are wrong: output-format isn't deprecated, and json output is supported. - Require -Z unstable-options for `--output-format json` Previously, it was allowed by default on nightly, which made it hard to realize the flag wouldn't be accepted on beta or stable. Note that this still allows `--output-format html`, which has been stable since 1.0. - Remove unnecessary double-checking of the feature gate when parsing the output format - Add custom run-make test since compiletest passes -Zunstable-options by default
2021-04-05change SourceSerifPro to SourceSerif4 in emit-shared-files testTrevor Spiteri-3/+3
2021-04-02Rollup merge of #83478 - jyn514:fine-grained-files, r=Mark-SimulacrumDylan DPC-0/+47
rustdoc: Add unstable option to only emit shared/crate-specific files The intended use case is for docs.rs, which can now copy exactly the files it cares about, rather than having to guess based on whether they have a resource suffix or not. In particular, some files have a resource suffix but cannot be shared between crates: https://github.com/rust-lang/docs.rs/pull/1312#issuecomment-798783688 The end goal is to fix rust-lang/docs.rs#1327 by reverting rust-lang/docs.rs#1324. This obsoletes `--print=unversioned-files`, which I plan to remove as soon as docs.rs stops using it. I recommend reviewing this one commit at a time. r? ``@GuillaumeGomez`` cc ``@Nemo157`` ``@pietroalbini``
2021-03-31Fix `--external-css` to be invocation-specific and note main.js should be ↵Joshua Nelson-7/+17
invocation specific
2021-03-31Rename CrateSpecific -> InvocationSpecificJoshua Nelson-11/+11
2021-03-31Enforce that Toolchain files are static and Crate files are dynamicJoshua Nelson-1/+5
This also changes custom themes from Toolchain to Crate files.
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-25Add unstable option to only emit shared/crate-specific filesJoshua Nelson-0/+33
The intended use case is for docs.rs, which can now copy exactly the files it cares about, rather than having to guess based on whether they have a resource suffix or not. In particular, some files have a resource suffix but cannot be shared between crates: https://github.com/rust-lang/docs.rs/pull/1312#issuecomment-798783688 The end goal is to fix https://github.com/rust-lang/docs.rs/issues/1327 by reverting https://github.com/rust-lang/docs.rs/pull/1324. This obsoletes `--print=unversioned-files`, which I plan to remove as soon as docs.rs stops using it.
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.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-27 01:48:29 +0000