about summary refs log tree commit diff
path: root/tests/run-make
AgeCommit message (Collapse)AuthorLines
2023-07-15Auto merge of #112157 - erikdesjardins:align, r=nikicbors-0/+245
Resurrect: rustc_target: Add alignment to indirectly-passed by-value types, correcting the alignment of byval on x86 in the process. Same as #111551, which I [accidentally closed](https://github.com/rust-lang/rust/pull/111551#issuecomment-1571222612) :/ --- This resurrects PR #103830, which has sat idle for a while. Beyond #103830, this also: - fixes byval alignment for types containing vectors on Darwin (see `tests/codegen/align-byval-vector.rs`) - fixes byval alignment for overaligned types on x86 Windows (see `tests/codegen/align-byval.rs`) - fixes ABI for types with 128bit requested alignment on ARM64 Linux (see `tests/codegen/aarch64-struct-align-128.rs`) r? `@nikic` --- `@pcwalton's` original PR description is reproduced below: Commit 88e4d2c from five years ago removed support for alignment on indirectly-passed arguments because of problems with the `i686-pc-windows-msvc` target. Unfortunately, the `memcpy` optimizations I recently added to LLVM 16 depend on this to forward `memcpy`s. This commit attempts to fix the problems with `byval` parameters on that target and now correctly adds the `align` attribute. The problem is summarized in [this comment] by `@eddyb.` Briefly, 32-bit x86 has special alignment rules for `byval` parameters: for the most part, their alignment is forced to 4. This is not well-documented anywhere but in the Clang source. I looked at the logic in Clang `TargetInfo.cpp` and tried to replicate it here. The relevant methods in that file are `X86_32ABIInfo::getIndirectResult()` and `X86_32ABIInfo::getTypeStackAlignInBytes()`. The `align` parameter attribute for `byval` parameters in LLVM must match the platform ABI, or miscompilations will occur. Note that this doesn't use the approach suggested by eddyb, because I felt it was overkill to store the alignment in `on_stack` when special handling is really only needed for 32-bit x86. As a side effect, this should fix #80127, because it will make the `align` parameter attribute for `byval` parameters match the platform ABI on LLVM x86-64. [this comment]: #80822 (comment)
2023-07-14extern-fn-explicit-align test: remove unnecessary derivesErik Desjardins-5/+0
2023-07-13extern fn-explicit-align test: don't use uint128_tErik Desjardins-3/+6
...which seems not to be available on some platforms. Or maybe it is under a different name but I don't want to deal with that Instead, use two u64s. This isn't exactly the same, but we already have some coverage of the packed u128 case in another test, so it's not essential to have it here.
2023-07-12De-duplicate consecutive libs when printing native-static-libsUrgau-1/+11
2023-07-11typeck in parallelSparrowLii-2/+2
2023-07-10aarch64-linux: properly handle 128bit aligned aggregatesErik Desjardins-4/+25
2023-07-10extern-fn-explicit-align test: add wrapped and lower requested alignment, ↵Erik Desjardins-14/+70
improve assertions
2023-07-10i686-windows: pass arguments with requested alignment > 4 indirectlyErik Desjardins-1/+5
2023-07-10extern-fn-struct-passing-abi test: ensure we don't start passing struct with ↵Erik Desjardins-0/+53
natural alignment > 8 by reference
2023-07-10extern-fn-explicit-align test: cleanupErik Desjardins-4/+6
2023-07-10extern-fn-explicit-align test: add MSVC compatible alignment attributeErik Desjardins-1/+10
2023-07-10extern-fn-explicit-align test: use ffi::c_char instead of i8Erik Desjardins-3/+3
2023-07-10add ignore-cross-compile to run-make/extern-fn-explicit-alignErik Desjardins-0/+1
From the test logs, other extern-fn-* tests have this: [run-make] tests/run-make/extern-fn-with-packed-struct ... ignored, ignored when cross-compiling [run-make] tests/run-make/extern-fn-with-union ... ignored, ignored when cross-compiling [run-make] tests/run-make/extern-multiple-copies ... ignored, ignored when cross-compiling [run-make] tests/run-make/extern-multiple-copies2 ... ignored, ignored when cross-compiling [run-make] tests/run-make/extern-overrides-distribution ... ignored, ignored when cross-compiling [run-make] tests/run-make/extra-filename-with-temp-outputs ... ignored, ignored when cross-compiling [run-make] tests/run-make/extern-fn-explicit-align ... FAILED
2023-07-10rustc_target: Add alignment to indirectly-passed by-value types, correcting thePatrick Walton-0/+101
alignment of `byval` on x86 in the process. Commit 88e4d2c2918428d55e34cd57c11279ea839c8822 from five years ago removed support for alignment on indirectly-passed arguments because of problems with the `i686-pc-windows-msvc` target. Unfortunately, the `memcpy` optimizations I recently added to LLVM 16 depend on this to forward `memcpy`s. This commit attempts to fix the problems with `byval` parameters on that target and now correctly adds the `align` attribute. The problem is summarized in [this comment] by @eddyb. Briefly, 32-bit x86 has special alignment rules for `byval` parameters: for the most part, their alignment is forced to 4. This is not well-documented anywhere but in the Clang source. I looked at the logic in Clang `TargetInfo.cpp` and tried to replicate it here. The relevant methods in that file are `X86_32ABIInfo::getIndirectResult()` and `X86_32ABIInfo::getTypeStackAlignInBytes()`. The `align` parameter attribute for `byval` parameters in LLVM must match the platform ABI, or miscompilations will occur. Note that this doesn't use the approach suggested by eddyb, because I felt it was overkill to store the alignment in `on_stack` when special handling is really only needed for 32-bit x86. As a side effect, this should fix #80127, because it will make the `align` parameter attribute for `byval` parameters match the platform ABI on LLVM x86-64. [this comment]: https://github.com/rust-lang/rust/pull/80822#issuecomment-829985417
2023-07-09Rollup merge of #113247 - mirkootter:test-wasm-exceptions-nostd, ↵Matthias Krüger-0/+252
r=Mark-Simulacrum Add Tests for native wasm exceptions ### Motivation In PR #111322, I added support for native WASM exceptions. I was asked by ``@davidtwco`` to add some tests for it in a follow up PR, which seems like a very good idea. This PR adds three tests for this feature: * codegen: ensure the correct LLVM instructions are used * assembly: ensure the correct WASM instructions are used * run-make: ensure the exception handling works; the WASM code is run using a small nodejs script which demonstrates the exception handling ### Complications There are a few changes beside adding the tests, which were necessary * Tests for the wasm32-unknown-unknown target are (as far as I know) only run on `test-various`. Its docker image uses nodejs-15, which is very old. Experimental support for wasm-exceptions was added in nodejs16. In nodejs 18.12 (LTS), they are stable. - --> increase nodejs to 18.12 in `test-various` * codegen/assembly tests are not performed for the wasm32-unknown-unknown target yet - --> add those to `test-various` as well Due to the last point, some tests are run which have not run before (assembly+codegen tests for wasm32-unknown-unknown). I added `// ignore wasm32-bare` for those which failed ### Local testing I run all tests locally using both `test-various` and `wasm32`. As far as I know, none of the other systems run any test for wasm32 targets.
2023-07-02Auto merge of #113040 - Kobzol:llvm-remark-streamer, r=tmiaskobors-0/+18
Add `-Zremark-dir` unstable flag to write LLVM optimization remarks to YAML This PR adds an option for `rustc` to emit LLVM optimization remarks to a set of YAML files, which can then be digested by existing tools, like https://github.com/OfekShilon/optview2. When `-Cremark-dir` is passed, and remarks are enabled (`-Cremark=all`), the remarks will be now written to the specified directory, **instead** of being printed to standard error output. The files are named based on the CGU from which they are being generated. Currently, the remarks are written using the LLVM streaming machinery, directly in the diagnostics handler. It seemed easier than going back to Rust and then form there back to C++ to use the streamer from the diagnostics handler. But there are many ways to implement this, of course, so I'm open to suggestions :) I included some comments with questions into the code. Also, I'm not sure how to test this. r? `@tmiasko`
2023-07-02Add `rustc` option to output LLVM optimization remarks to YAML filesJakub Beránek-0/+18
2023-07-01add run-make test for wasm-exceptionsJan-Mirko Otter-0/+252
2023-06-30add end-to-end testRémy Rakic-0/+12
2023-06-29Rollup merge of #112300 - Zalathar:run-coverage, r=wesleywiserMatthias Krüger-5593/+1
Convert `run-make/coverage-reports` tests to use a custom compiletest mode I was frustrated by the fact that most of the coverage tests are glued together with makefiles and shell scripts, so I tried my hand at converting most of them over to a newly-implemented `run-coverage` mode/suite in compiletest. This ~~*mostly*~~ resolves #85009, ~~though I've left a small number of the existing tests as-is because they would require more work to fix/support~~. --- I had time to go back and add support for the more troublesome tests that I had initially skipped over, so this PR now manages to completely get rid of `run-make/coverage-reports`. --- The patches are arranged as follows: - Declare the new mode/suite in bootstrap - Small changes to compiletest that will be used by the new mode - Implement the new mode in compiletest - Migrate most of the tests over - Add more code to bootstrap and compiletest to support the remaining tests - Migrate the remaining tests (with some temporary hacks to avoid re-blessing them) - Remove the temporary hacks and re-bless the migrated tests - Remove the unused remnants of `run-make/coverage-reports`
2023-06-28Rollup merge of #113094 - GuillaumeGomez:fix-invalid-div-tag-in-head, ↵Dylan DPC-1/+1
r=notriddle,fmease Fix invalid HTML DIV tag used in HEAD Fixes https://github.com/rust-lang/rust/issues/113067. The issue also nicely explains the whole problem. r? ``@notriddle``
2023-06-28Remove the old `coverage-reports` and `coverage` directoriesZalathar-264/+1
2023-06-28Migrate the remaining `run-make/coverage-reports` tests over to `run-coverage`Zalathar-816/+0
To make it easier to verify that the output snapshots have been migrated faithfully, this change adds some temporary helper code that lets us avoid having to completely re-bless the existing snapshots. A later change in this PR will then re-bless the tests and remove the temporary helper code.
2023-06-28Migrate most of the existing coverage tests over to `run-coverage`Zalathar-4517/+4
2023-06-27Replace `id` attribute with `name` for `<meta>` tagGuillaume Gomez-1/+1
2023-06-27Rollup merge of #112972 - nbdd0121:mir, r=davidtwcoMatthias Krüger-3/+3
Make `UnwindAction::Continue` explicit in MIR dump Makes it easier to spot unwinding related issues in MIR by making `UnwindAction::Continue` explicit, just like all other `UnwindAction`s.
2023-06-23Bless testsGary Guo-3/+3
2023-06-23Make sure to include default en-US ftl resources for rustc_error crateMichael Goulet-0/+12
2023-06-20Rollup merge of #112794 - bjorn3:fix_lib_global_alloc, r=oli-obkGuillaume Gomez-0/+22
Fix linker failures when #[global_allocator] is used in a dependency Fixes https://github.com/rust-lang/rust/issues/112715
2023-06-19Rollup merge of #112499 - tgross35:py-ruff-fixes, r=Mark-SimulacrumMichael Goulet-3/+3
Fix python linting errors These were flagged by `ruff`, run using the config in https://github.com/rust-lang/rust/pull/112482
2023-06-19Fix linker failures when #[global_allocator] is used in a dependencybjorn3-0/+22
2023-06-17rustdoc: Fix --test-run-directory and relative paths.Eric Huss-1/+46
2023-06-16Apply changes to fix python linting errorsTrevor Gross-3/+3
2023-06-16Auto merge of #112346 - saethlin:no-comment, r=oli-obkbors-19/+16
Remove comments from mir-opt MIR dumps See https://rust-lang.zulipchat.com/#narrow/stream/189540-t-compiler.2Fwg-mir-opt/topic/Line.20numbers.20in.20mir-opt.20tests/near/363849874 In https://github.com/rust-lang/rust/pull/99780 there is mention that "there has been a zulip conversation about disabling line numbers with mixed opinions" which to me means that some people opposed this. I can't find the referenced conversation so... here we go. The current situation is quite chaotic. It's not hard to find MIR diffs which contain * Absolute line numbers * Relative line numbers * Substituted line numbers (LL) For example: https://github.com/rust-lang/rust/blob/408bbd040613f6776e0a7d05d582c81f4ddc189a/tests/mir-opt/inline/inline_shims.drop.Inline.diff#L10-L17 And sometimes adding a comment at the top of a mir-opt test generates a diff in the test because a line number changed: https://github.com/rust-lang/rust/pull/98112/files#diff-b8cf4bcce95078e6a3faf075e9abf6864872fb28a64d95c04f04513b9e3bbd81 And irrelevant changes to the standard library can generate diffs in mir-opt tests: https://github.com/rust-lang/rust/pull/110694/files#diff-bf96b0e7c67b8b272814536888fd9428c314991e155beae1f0a2a67f0ac47b2c https://github.com/rust-lang/rust/commit/769886cc35ce08b76839f4cf72b8af1161c432e1 I think we should, specifically in mir-opt tests, completely remove the comments, or insert placeholders for all line and column numbers.
2023-06-15Rollup merge of #112403 - nbdd0121:eh_frame, r=NilstriebGuillaume Gomez-0/+20
Prevent `.eh_frame` from being emitted for `-C panic=abort` Since `CheckAlignment` pass is after the `AbortUnwindingCalls` pass, the `UnwindAction::Terminate` inserted in it has no chance to be converted to `UnwindAction::Unreachable` anymore, causing us to emit landing pads that are not necessary. Although these landing pads can themselves be eliminated by LLVM, `.eh_frame` sections are still generated. This causes trouble for Rust-for-Linux project recently. This PR changes it to generate `UnwindAction::Terminate` when we opt for `-Cpanic=unwind`, and `UnwindAction::Unreachable` for `-Cpanic=abort`. `@ojeda`
2023-06-15Remove comments from mir-opt MIR dumpsBen Kimock-19/+16
2023-06-09Auto merge of #111626 - pjhades:output, r=b-naberbors-0/+72
Write to stdout if `-` is given as output file With this PR, if `-o -` or `--emit KIND=-` is provided, output will be written to stdout instead. Binary output (those of type `obj`, `llvm-bc`, `link` and `metadata`) being written this way will result in an error unless stdout is not a tty. Multiple output types going to stdout will trigger an error too, as they will all be mixded together. This implements https://github.com/rust-lang/compiler-team/issues/431 The idea behind the changes is to introduce an `OutFileName` enum that represents the output - be it a real path or stdout - and to use this enum along the code paths that handle different output types.
2023-06-07Remove wrongly emitted `.eh_frame` in `-Cpanic=abort`Gary Guo-0/+20
2023-06-06fixJing Peng-1/+1
- remove useless commands from test Makefile - do not unnecessarily remove metadata temporary files because they'll be managed by MaybeTempDir - remove unused FailedRemove error introduced by this PR
2023-06-06Write to stdout if `-` is given as output fileJing Peng-0/+72
If `-o -` or `--emit KIND=-` is provided, output will be written to stdout instead. Binary output (`obj`, `llvm-bc`, `link` and `metadata`) being written this way will result in an error unless stdout is not a tty. Multiple output types going to stdout will trigger an error too, as they will all be mixded together.
2023-06-05Verify that (almost) all `ret` instructions have been replacedRaoul Strackx-0/+9
2023-06-05Correct LVI print function testRaoul Strackx-4/+4
2023-05-25Auto merge of #86844 - bjorn3:global_alloc_improvements, r=pnkfelixbors-0/+68
Support #[global_allocator] without the allocator shim This makes it possible to use liballoc/libstd in combination with `--emit obj` if you use `#[global_allocator]`. This is what rust-for-linux uses right now and systemd may use in the future. Currently they have to depend on the exact implementation of the allocator shim to create one themself as `--emit obj` doesn't create an allocator shim. Note that currently the allocator shim also defines the oom error handler, which is normally required too. Once `#![feature(default_alloc_error_handler)]` becomes the only option, this can be avoided. In addition when using only fallible allocator methods and either `--cfg no_global_oom_handling` for liballoc (like rust-for-linux) or `--gc-sections` no references to the oom error handler will exist. To avoid this feature being insta-stable, you will have to define `__rust_no_alloc_shim_is_unstable` to avoid linker errors. (Labeling this with both T-compiler and T-lang as it originally involved both an implementation detail and had an insta-stable user facing change. As noted above, the `__rust_no_alloc_shim_is_unstable` symbol requirement should prevent unintended dependence on this unstable feature.)
2023-05-23Rollup merge of #111461 - oli-obk:crate_collision, r=petrochenkovDylan DPC-1/+1
Fix symbol conflict diagnostic mistakenly being shown instead of missing crate diagnostic This was a refactoring mistake in https://github.com/rust-lang/rust/pull/109213 fixes #111284
2023-05-23Fix symbol conflict diagnostic mistakenly being shown instead of missing ↵Oli Scherer-1/+1
crate diagnostic
2023-05-21Auto merge of #111675 - Urgau:fix-local-libs-for-native-static-libs, r=bjorn3bors-0/+43
Fix local libs not included when printing native static libs This PR fixes https://github.com/rust-lang/rust/issues/111643 by adding the local used libs to the printed `--print=native-static-libs` output. It seems that `--print=native-static-libs` doesn't have any test, so I added one. It's very simple and doesn't even tries to compile the result to a binary as I don't know how to handle external library linking in CI. (Note that https://github.com/rust-lang/rust/blob/master/tests/run-make/staticlib-dylib-linkage/Makefile does compile to a binary) r? `@bjorn3`
2023-05-19Auto merge of #111641 - michaelwoerister:debugger-visualizer-fixes, r=cjgillotbors-0/+78
Fix dependency tracking for debugger visualizers This PR fixes dependency tracking for debugger visualizer files by changing the `debugger_visualizers` query to an `eval_always` query that scans the AST while it is still available. This way the set of visualizer files is already available when dep-info is emitted. Since the query is turned into an `eval_always` query, dependency tracking will now reliably detect changes to the visualizer script files themselves. TODO: - [x] perf.rlo - [x] Needs a bit more documentation in some places - [x] Needs regression test for the incr. comp. case Fixes https://github.com/rust-lang/rust/issues/111226 Fixes https://github.com/rust-lang/rust/issues/111227 Fixes https://github.com/rust-lang/rust/issues/111295 r? `@wesleywiser` cc `@gibbyfree`
2023-05-19Fix run-make/inrcemental-debugger-visualizer test for macOS.Michael Woerister-3/+1
2023-05-18Auto merge of #111345 - jyn514:cfg-release-caching, r=cjgillot,est31bors-0/+15
Only depend on CFG_VERSION in rustc_interface This avoids having to rebuild the whole compiler on each commit when `omit-git-hash = false`. cc https://github.com/rust-lang/rust/issues/76720 - this won't fix it, and I'm not suggesting we turn this on by default, but it will make it less painful for people who do have `omit-git-hash` on as a workaround.
2023-05-17Only depend on CFG_VERSION in rustc_interfacejyn-0/+15
this avoids having to rebuild the whole compiler on each commit when `omit-git-hash = false`.
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-04-25 21:44:12 +0000