Files
rust/tests/ui
Guillaume Gomez 99d0feedb8 Rollup merge of #126075 - compiler-errors:remove-debugwithinfcx, r=lcnr
Remove `DebugWithInfcx` machinery

This PR removes `DebugWithInfcx` after having a lot of second thoughts about it due to recent type system uplifting work. We could add it back later if we want, but I don't think the amount of boilerplate in the complier and the existence of (kindof) hacks like `NoInfcx` currently justify the existence of `DebugWithInfcx`, especially since it's not even being used anywhere in the compiler currently.

The motivation for `DebugWithInfcx` is that we want to be able to print infcx-aware information, such as universe information[^1] (though if there are other usages that I'm overlooking, please let me know). I think there are probably more tailored solutions that can specifically be employed in places where this infcx-aware printing is necessary. For example, one way of achieving this is by implementing a custom `FmtPrinter` which overloads `ty_infer_name` (perhaps also extending it to have overrideable stubs for printing placeholders too) to print the `?u.i` name for an infer var. This will necessitate uplifting `Print` from `rustc_middle::ty::print`, but this seems a bit more extensible and reusable than `DebugWithInfcx`.

One of the problems w/ `DebugWithInfcx` is its opt-in-ness. Even if a compiler dev adds a new `debug!(ty)` in a context where there is an `infcx` we can access, they have to *opt-in* to using `DebugWithInfcx` with something like `debug!(infcx.with(ty))`. This feels to me like it risks a lot of boilerplate, and very easy to just forget adding it at all, especially in cases like `#[instrument]`.

A second problem is the `NoInfcx` type itself. It's necessary to have this dummy infcx implementation since we often want to print types outside of the scope of a valid `Infcx`. Right now, `NoInfcx` is only *partially* a valid implementation of `InferCtxtLike`, except for the methods that we specifically need for `DebugWithInfcx`. As I work on uplifting the trait solver, I actually want to add a lot more methods to `InferCtxtLike` and having to add `unreachable!("this should never be called")` stubs for uplifted methods like `next_ty_var` is quite annoying.

In reality, I actually only *really* care about the second problem -- we could, perhaps, instead just try to get rid of `NoInfcx` and just just duplicate `Debug` and `DebugWithInfcx` for most types. If we're okay with duplicating all these implementations (though most of them would just be trivial `#[derive(Debug, DebugWithInfcx)]`), I'd be okay with that too 🤔

r? `@BoxyUwU` `@lcnr` would like to know your thoughts -- happy to discuss this further, mainly trying to bring this problem up

[^1]: Which in my experience is only really necessary when we're debugging things like generalizer bugs.
2024-06-12 15:44:58 +02: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-06-11 22:13:04 -04: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-11 22:13:04 -04: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-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-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-02-07 10:42:01 +08: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>.