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
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();
| +++++++++++++++ +
```
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
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 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
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.
Fix ICE Caused by Incorrectly Delaying E0107
Fixes #128249
For the following code:
```rust
trait Foo<T> {}
impl Foo<T: Default> for u8 {}
```
#126054 added some logic to delay emitting E0107 as the names of associated type `T` in the impl header and generic parameter `T` in `trait Foo` match.
But it failed to ensure whether such unexpected associated type bounds are coming from a impl block header. This caused an ICE as the compiler was delaying E0107 for code like:
```rust
trait Trait<Type> {
type Type;
fn method(&self) -> impl Trait<Type: '_>;
}
```
because it assumed the associated type bound `Type: '_` is for the generic parameter `Type` in `trait Trait` since the names are same.
This PR adds a check to ensure that E0107 is delayed only in the context of impl block header.
Migrate `cdylib-dylib-linkage` `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).
~~Those sysroot tests are always fun. I'm getting local errors that don't make a lot of sense about my own sysroot not existing, so I am trying this in CI to see what happens.~~
~~EDIT: I am getting the same error here. The strange thing is, when I try to navigate to `/checkout/obj/build/x86_64-unknown-linux-gnu/stage2/lib/rustlib/x86_64-unknown-linux-gnu/lib` on my personal computer, the directory does exist, but the error message is that the directory does not.~~
EDIT 2: The sysroot path just needed to be trimmed!
Please try:
// try-job: x86_64-msvc // passed previously
try-job: x86_64-mingw
try-job: x86_64-gnu-llvm-18
try-job: i686-msvc
try-job: aarch64-apple
On short error format, append primary span label to message
The `error-format=short` output only displays the path, error code and main error message all in the same line. We now add the primary span label as well after the error message, to provide more context.
The `error-format=short` output only displays the path, error code and
main error message all in the same line. We now add the primary span label
as well after the error message, to provide more context.
Tweak type inference for `const` operands in inline asm
Previously these would be treated like integer literals and default to `i32` if a type could not be determined. To allow for forward-compatibility with `str` constants in the future, this PR changes type inference to use an unbound type variable instead.
The actual type checking is deferred until after typeck where we still ensure that the final type for the `const` operand is an integer type.
<!--
If this PR is related to an unstable feature or an otherwise tracked effort,
please link to the relevant tracking issue here. If you don't know of a related
tracking issue or there are none, feel free to ignore this.
This PR will get automatically assigned to a reviewer. In case you would like
a specific user to review your work, you can assign it to them by using
r? <reviewer name>
-->
interpret: move nullary-op evaluation into operator.rs
We call it an operator, so we might as well treat it like one. :)
Also use more consistent naming for the "evaluate intrinsic" functions. "emulate" is really the wrong term, this *is* a genuine implementation of the intrinsic semantics after all.
Use `ParamEnv::reveal_all` in CFI
I left a huge comment for why this ICEs in the test I committed.
`typeid_for_instance` should only be called on monomorphic instances during codegen, and we should just be using `ParamEnv::reveal_all()` rather than the param-env of the instance itself. I added an assertion to ensure that we only do this for fully substituted instances (this may break with polymorphization, but I kinda don't care lol).
Fixes#114160
cc `@rcvalle`
Enforce supertrait outlives obligations hold when confirming impl
**TL;DR:** We elaborate super-predicates and apply any outlives obligations when proving an impl holds to fix a mismatch between implied bounds.
Bugs in implied bounds (and implied well-formedness) occur whenever there is a mismatch between the assumptions that some code can assume to hold, and the obligations that a caller/user of that code must prove. If the former is stronger than the latter, then unsoundness occurs.
Take a look at the example unsoundness:
```rust
use std::fmt::Display;
trait Static: 'static {}
impl<T> Static for &'static T {}
fn foo<S: Display>(x: S) -> Box<dyn Display>
where
&'static S: Static,
{
Box::new(x)
}
fn main() {
let s = foo(&String::from("blah blah blah"));
println!("{}", s);
}
```
This specific example occurs because we elaborate obligations in `fn foo`:
* `&'static S: Static`
* `&'static S: 'static` <- super predicate
* `S: 'static` <- elaborating outlives bounds
However, when calling `foo`, we only need to prove the direct set of where clauses. So at the call site for some substitution `S = &'not_static str`, that means only proving `&'static &'not_static str: Static`. To prove this, we apply the impl, which itself holds trivially since it has no where clauses.
This is the mismatch -- `foo` is allowed to assume that `S: 'static` via elaborating supertraits, but callers of `foo` never need to prove that `S: 'static`.
There are several approaches to fixing this, all of which have problems due to current limitations in our type system:
1. proving the elaborated set of predicates always - This leads to issues since we don't have coinductive trait semantics, so we easily hit new cycles.
* This would fix our issue, since callers of `foo` would have to both prove `&'static &'not_static str: Static` and its elaborated bounds, which would surface the problematic `'not_static: 'static` outlives obligation.
* However, proving supertraits when proving impls leads to inductive cycles which can't be fixed until we get coinductive trait semantics.
2. Proving that an impl header is WF when applying that impl:
* This would fix our issue, since when we try to prove `&'static &'not_static str: Static`, we'd need to prove `WF(&'static &'not_static str)`, which would surface the problematic `'not_static: 'static` outlives obligation.
* However, this leads to issues since we don't have higher-ranked implied bounds. This breaks things when trying to apply impls to higher-ranked trait goals.
To get around these limitations, we apply a subset of (1.), which is to elaborate the supertrait obligations of the impl but filter only the (region/type) outlives out of that set, since those can never participate in an inductive cycle. This is likely not sufficient to fix a pathological example of this issue, but it does clearly fill in a major gap that we're currently overlooking.
This can also result in 'unintended' errors due to missing implied-bounds on binders. We did not encounter this in the crater run and don't expect people to rely on this code in practice:
```rust
trait Outlives<'b>: 'b {}
impl<'b, T> Outlives<'b> for &'b T {}
fn foo<'b>()
where
// This bound will break due to this PR as we end up proving
// `&'b &'!a (): 'b` without the implied `'!a: 'b`
// bound.
for<'a> &'b &'a (): Outlives<'b>,
{}
```
Fixes#98117
---
Crater: https://github.com/rust-lang/rust/pull/124336#issuecomment-2209165320
Triaged: https://github.com/rust-lang/rust/pull/124336#issuecomment-2236321325
All of the fallout is due to generic const exprs, and can be ignored.
