Files
rust/tests/ui
bors 336e6ab3b3 Auto merge of #126139 - compiler-errors:specializes, r=lcnr
Only compute `specializes` query if (min)specialization is enabled in the crate of the specializing impl

Fixes (after backport) https://github.com/rust-lang/rust/issues/125197

### What

https://github.com/rust-lang/rust/pull/122791 makes it so that inductive cycles are no longer hard errors. That means that when we are testing, for example, whether these impls overlap:

```rust
impl PartialEq<Self> for AnyId {
    fn eq(&self, _: &Self) -> bool {
        todo!()
    }
}

impl<T: Identifier> PartialEq<T> for AnyId {
    fn eq(&self, _: &T) -> bool {
        todo!()
    }
}
```

...given...

```rust
pub trait Identifier: Display + 'static {}

impl<T> Identifier for T where T: PartialEq + Display + 'static {}
```

Then we try to see if the second impl holds given `T = AnyId`. That requires `AnyId: Identifier`, which requires that `AnyId: PartialEq`, which is satisfied by these two impl candidates... The `PartialEq<T>` impl is a cycle, and we used to winnow it when we used to treat inductive cycles as errors.

However, now that we don't winnow it, this means that we *now* try calling `candidate_should_be_dropped_in_favor_of`, which tries to check whether one of the impls specializes the other: the `specializes` query. In that query, we currently bail early if the impl is local.

However, in a foreign crate, we try to compute if the two impls specialize each other by doing trait solving. This may itself lead to the same situation where we call `specializes`, which will lead to a query cycle.

### How does this fix the problem

We now record whether specialization is enabled in foreign crates, and extend this early-return behavior to foreign impls too. This means that we can only encounter these cycles if we truly have a specializing impl from a crate with specialization enabled.

-----

r? `@oli-obk` or `@lcnr`
2024-06-11 07:01:18 +00:00
..
2024-06-06 20:27:25 -05:00
2024-05-02 19:42:31 -04:00
2024-04-16 18:15:37 -04:00
2024-05-21 20:16:39 +00:00
2024-04-21 15:43:43 -03:00
2024-02-01 03:31:03 +00:00
2024-03-06 12:01:54 +00:00
2024-04-21 15:43:43 -03:00
2024-04-14 21:34:14 +05:30
2024-04-12 20:57:07 +00:00
2024-06-01 09:40:46 +08:00
2024-06-07 08:33:58 +00:00
2024-05-20 19:21:30 -04:00
2024-04-12 17:45:15 +01:00
2024-04-29 14:53:38 +02:00
2024-04-25 10:47:24 +08:00
2024-05-20 11:13:10 -04:00
2024-04-07 17:38:07 -03:00
2024-05-19 19:10:04 +02:00
2024-05-28 12:31:12 +02:00
2024-04-11 17:53:27 -04:00
2024-04-21 15:43:43 -03:00
2024-02-29 14:43:43 +01:00
2024-05-30 15:26:48 +02:00
2024-05-20 20:30:44 +02:00
2024-05-21 20:16:39 +00:00
2024-04-27 10:54:31 +03:00
2024-04-25 10:51:54 -04:00
2024-03-15 13:37:41 +00:00
2024-05-21 20:16:39 +00:00
2024-04-27 10:54:31 +03:00
2024-06-05 22:25:42 +01:00
2024-02-22 18:05:28 +00:00
2024-01-13 12:46:58 -05:00
2024-02-07 10:42:01 +08:00
2024-01-13 12:46:58 -05:00
2024-02-07 10:42:01 +08: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>.