Matthias Krüger e903b29dc3
Rollup merge of #129021 - compiler-errors:ptr-cast-outlives, r=lcnr
Check WF of source type's signature on fn pointer cast

This PR patches the implied bounds holes slightly for #129005, #25860.

Like most implied bounds related unsoundness fixes, this isn't complete w.r.t. higher-ranked function signatures, but I believe it implements a pretty good heuristic for now.

### What does this do?

This PR makes a partial patch for a soundness hole in a `FnDef` -> `FnPtr` "reifying" pointer cast where we were never checking that the signature we are casting *from* is actually well-formed. Because of this, and because `FnDef` doesn't require its signature to be well-formed (just its predicates must hold), we are essentially allowed to "cast away" implied bounds that are assumed within the body of the `FnDef`:

```
fn foo<'a, 'b, T>(_: &'a &'b (), v: &'b T) -> &'a T { v }

fn bad<'short, T>(x: &'short T) -> &'static T {
    let f: fn(_, &'short T) -> &'static T = foo;
    f(&&(), x)
}
```

In this example, subtyping ends up casting the `_` type (which should be `&'static &'short ()`) to some other type that no longer serves as a "witness" to the lifetime relationship `'short: 'static` which would otherwise be required for this call to be WF. This happens regardless of if `foo`'s lifetimes are early- or late-bound.

This PR implements two checks:
1. We check that the signature of the `FnDef` is well-formed *before* casting it. This ensures that there is at least one point in the MIR where we ensure that the `FnDef`'s implied bounds are actually satisfied by the caller.
2. Implements a special case where if we're casting from a higher-ranked `FnDef` to a non-higher-ranked, we instantiate the binder of the `FnDef` with *infer vars* and ensure that it is a supertype of the target of the cast.

The (2.) is necessary to validate that these pointer casts are valid for higher-ranked `FnDef`. Otherwise, the example above would still pass even if `help`'s `'a` lifetime were late-bound.

### Further work

The WF checks for function calls are scattered all over the MIR. We check the WF of args in call terminators, we check the WF of `FnDef` when we create a `const` operand referencing it, and we check the WF of the return type in #115538, to name a few.

One way to make this a bit cleaner is to simply extend #115538 to always check that the signature is WF for `FnDef` types. I may do this as a follow-up, but I wanted to keep this simple since this leads to some pretty bad NLL diagnostics regressions, and AFAICT this solution is *complete enough*.

### Crater triage

Done here: https://github.com/rust-lang/rust/pull/129021#issuecomment-2297702647

r? lcnr
2024-09-06 07:33:56 +02:00
..
2024-07-28 03:11:54 +08:00
2024-07-29 21:47:19 -04:00
2024-08-28 23:32:40 +01:00
2024-09-03 09:19:29 +02:00
2024-08-10 12:07:17 +02:00
2024-08-09 22:02:23 -04:00
2024-08-10 12:07:17 +02:00
2024-08-28 23:32:40 +01:00
2024-08-02 11:34:54 +00:00
2024-09-05 06:37:38 -04:00
2024-08-18 19:46:53 +02:00
2024-08-18 19:46:53 +02:00
2024-08-10 12:07:17 +02:00
2024-08-18 19:46:53 +02:00
2024-08-02 11:34:54 +00:00
2024-08-12 13:00:12 +10:00
2024-08-02 11:34:54 +00:00
2024-08-03 07:57:31 -04:00
2024-08-18 19:46:53 +02:00
2024-09-02 21:16:37 +02:00
2024-08-31 23:56:45 +02:00
2024-09-03 14:36:21 +02:00
2024-07-22 22:51:53 +00:00
2024-08-18 19:46:53 +02:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2023-01-11 09:32:08 +00:00
2024-06-25 18:06:22 +02:00
2023-01-11 09:32:08 +00:00

UI Tests

This folder contains rustc's UI tests.

Test Directives (Headers)

Typically, a UI test will have some test directives / headers which are special comments that tell compiletest how to build and intepret a test.

As part of an on-going effort to rewrite compiletest (see https://github.com/rust-lang/compiler-team/issues/536), a major change proposal to change legacy compiletest-style headers // <directive> to ui_test-style headers //@ <directive> was accepted (see https://github.com/rust-lang/compiler-team/issues/512.

An example directive is ignore-test. In legacy compiletest style, the header would be written as

// ignore-test

but in ui_test style, the header would be written as

//@ ignore-test

compiletest is changed to accept only //@ directives for UI tests (currently), and will reject and report an error if it encounters any comments // <content> that may be parsed as an legacy compiletest-style test header. To fix this, you should migrate to the ui_test-style header //@ <content>.