Rollup of 9 pull requests
Successful merges:
- #128206 (Make create_dll_import_lib easier to implement)
- #128424 (minor `effects` cleanups)
- #128527 (More information for fully-qualified suggestion when there are multiple impls)
- #128656 (Enable msvc for run-make/rust-lld)
- #128683 (bootstrap: clear miri's ui test deps when rustc changes)
- #128700 (Migrate `simd-ffi` `run-make` test to rmake)
- #128753 (Don't arbitrarily choose one upper bound for hidden captured region error message)
- #128757 (Migrate `pgo-gen-lto` `run-make` test to rmake)
- #128758 (Specify a minimum supported version for VxWorks)
Failed merges:
- #128679 (codegen: better centralize function declaration attribute computation)
r? `@ghost`
`@rustbot` modify labels: rollup
Migrate `pgo-gen-lto` `run-make` test to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
This one is so easy, I'm surprised I missed it.
try-job: aarch64-apple
try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: i686-msvc
try-job: i686-mingw
try-job: x86_64-gnu-llvm-17
Don't arbitrarily choose one upper bound for hidden captured region error message
You could argue that the error message is objectively worse, even though it's more accurate. I guess we could also add a note explaining like "cannot capture the intersection of two regions" or something, though I'm not sure if that is confusing due to being totally technical jargon.
This addresses the fact that #128752 says "add `+ 'b`" even though it does nothing to fix the issue. It doesn't fix the issue's root cause, though.
r? `@spastorino`
Migrate `simd-ffi` `run-make` test to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
try-job: x86_64-msvc
try-job: x86_64-mingw
try-job: i686-msvc
try-job: armhf-gnu
try-job: test-various
try-job: aarch64-apple
try-job: x86_64-gnu-llvm-17
bootstrap: clear miri's ui test deps when rustc changes
`@onur-ozkan` I hope this makes sense... it's quite hard to test this, but it did at least cause one rebuild of the right files for me, and then it doesn't seem to keep rebuilding, so at first sight this look at least better than the status quo.
Enable msvc for run-make/rust-lld
This is simply a matter of using the right argument for lld-link.
As a bonus, I also fixed a typo.
try-job: i686-msvc
try-job: x86_64-msvc
More information for fully-qualified suggestion when there are multiple impls
```
error[E0790]: cannot call associated function on trait without specifying the corresponding `impl` type
--> $DIR/E0283.rs:30:21
|
LL | fn create() -> u32;
| ------------------- `Coroutine::create` defined here
...
LL | let cont: u32 = Coroutine::create();
| ^^^^^^^^^^^^^^^^^^^ cannot call associated function of trait
|
help: use a fully-qualified path to a specific available implementation
|
LL | let cont: u32 = <Impl as Coroutine>::create();
| ++++++++ +
LL | let cont: u32 = <AnotherImpl as Coroutine>::create();
| +++++++++++++++ +
```
minor `effects` cleanups
* remove the fixme comment about not needing defaults because it turns out we do need defaults (if I made it None instead it would ice a bunch of tests)
* remove the part that special cased trait args when lowering them. This is now historical because effects doesn't add host args to traits anymore (we use associated types now)
Make create_dll_import_lib easier to implement
This will make it easier to implement raw-dylib support in cg_clif and cg_gcc. This PR doesn't yet include an create_dll_import_lib implementation for cg_clif as I need to correctly implement dllimport in cg_clif first before raw-dylib can work at all with cg_clif.
Required for https://github.com/rust-lang/rustc_codegen_cranelift/issues/1345
Migrate `cross-lang-lto-upstream-rlibs`, `long-linker-command-lines` and `long-linker-command-lines-cmd-exe` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
The `long-linker` tests are certainly doing something... interesting - they summon `rustc` calls with obscene quantities of arguments and check that this is appropriately handled. I removed the `RUSTC_ORIGINAL` magic - it's equivalent to `RUSTC` in `tools.mk`, so what is the purpose? Making it so the massive pile of flags doesn't modify rustc itself and start leaking into other tests? Tell me what you think.
Please try:
try-job: x86_64-msvc
try-job: i686-msvc
try-job: x86_64-mingw
try-job: i686-mingw
try-job: aarch64-apple
try-job: test-various
try-job: x86_64-gnu-debug
try-job: x86_64-gnu-llvm-17
Version 0.3.1 has added support for writing import libraries. Version
0.3.2 fixed creating archives containing members of import libraries.
Version 0.3.3 fixed building on big-endian systems.
Most float functions are marked `#[inline]` so any float symbols used by
these functions only need to be provided if the function itself is used.
RFL recently noticed that `next_up`, `next_down`, and `midpoint` for
`f32` and `f64` are not inline, which causes linker errors when building
with certain configurations [1].
Add the missing attributes so the symbols should no longer be required.
Cc: Gary Guo <gary@garyguo.net>
Reported-by: Alice Ryhl <aliceryhl@google.com>
Link: https://lore.kernel.org/all/20240806150619.192882-1-ojeda@kernel.org/ [1]
The object crate was recently updated to recognize the 32-bit SPARC
ELF targets EM_SPARC and EM_SPARC32PLUS, so the proper architecture
for 32-bit SPARC can now be set in rustc_codegen_ssa.
Update cargo
3 commits in fa646583675d7c140482bd906145c71b7fb4fc2b..94977cb1fab003d45eb5bb108cb5e2fa0149672a
2024-08-02 16:08:06 +0000 to 2024-08-06 21:42:10 +0000
- Don't specify the depedency name in the `cargo add` inferred name test (rust-lang/cargo#14357)
- Fix renamed disallowed cfg lint name (rust-lang/cargo#14352)
- fix(build-std): remove hack on creating virtual std workspace (rust-lang/cargo#14358)
r? ghost
Trivial grammar fix in const keyword docs
This PR makes a trivial fix to the wording of a sentence in the `const` keyword docs.
> `const` items looks remarkably similar to `static` items, [...]
Either this should be written as
> A `const` items looks remarkably similar to a `static` item, [...]
or "looks" should be changed to "look".
I have selected the smaller diff.
run-make: Enable msvc for `no-duplicate-libs` and `zero-extend-abi-param-passing`
The common thing between these two tests is to use `#[link(..., kind="static")]` so that it doesn't try to do a DLL import.
`zero-extend-abi-param-passing` also needs to have an optimized static library but there's only helper function for a non-optimized version. Rather than copy/pasting the code (and adding the optimization flag) I reused the same code so that it more easily be kept in sync.
try-job: i686-msvc
try-job: x86_64-msvc
Enable msvc for link-args-order
I could not see any reason in #70665 why this test needs to specifically use `ld`. Maybe to provide a consistent linker input line? In any case, the test does work for the MSVC linker.
try-job: i686-msvc
try-job: x86_64-msvc
run-make: enable msvc for `link-dedup`
This is just a case of differing style of linker arguments.
I also cleaned up a bit where we were running the same command three times in a row. Instead I reused the output.
One thing that confused me is why we were testing for the same lib three times in a row but not two. After figuring that out I added a note to hopefully save future readers some confusion.
try-job: x86_64-msvc
try-job: i686-msvc
Add `f16` and `f128` math functions
This adds intrinsics and math functions for `f16` and `f128` floating point types. Support is quite limited and some things are broken so tests don't run on many platforms, but this provides a starting point.
add test for symbol visibility of `#[naked]` functions
tracking issue: #90957
This test is extracted from https://github.com/rust-lang/rust/pull/128004
That PR attempts to generated naked functions as an extern function declaration, combined with a global asm block that provides the implementation for that declaration.
In order to link declaration and definition together, some flavor of external linking must be used: LLVM will error for other linkage types. Specifically the allowed options are `#[linkage = "external"]` and `#[linkage = "extern_weak"]`. That is kind of an implementation detail though: to the user, a naked function should just behave like a normal function.
Hence it should be visible to the linker under the same circumstances as a normal, vanilla function and have the same attributes (Weak, External). Getting this behavior right will require some care, so I think it's a good idea to lock it in now, before making any changes, to make sure we don't regress.
Are there any interesting cases that I missed here? E.g. is checking on different architectures worth it? I don't think the other binary types (rlib etc) are relevant here, but may be missing something.
r? ``@bjorn3``
Migrate `raw-dylib-alt-calling-convention`, `raw-dylib-c` and `redundant-libs` `run-make` tests to rmake
Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).
Please try:
// try-job: x86_64-msvc
// try-job: x86_64-mingw
// try-job: i686-msvc
try-job: x86_64-gnu-llvm-17
try-job: aarch64-apple
> `const` items looks remarkably similar to `static` items, [...]
Either this should be written as
> A `const` items looks remarkably similar to a `static` item,
or "looks" should be changed to "look".
I have selected the smaller diff.
Don't ICE when getting an input file name's stem fails
Fixes#128681
The file stem is only used as a user-friendly prefix on intermediary files. While nice to have, it's not the end of the world if it fails so there's no real reason to emit an error here. We can continue with a fixed name as we do when an anonymous string is used.
Add a triagebot mention for `library/Cargo.lock`
Since [1], `Cargo.lock` was split into `Cargo.lock` and `library/Cargo.lock`. Update Triagebot to give the same warning for both.
[1]: https://github.com/rust-lang/rust/pull/128534
