Do not deduce parameter attributes during CTFE
*[View all comments](https://triagebot.infra.rust-lang.org/gh-comments/rust-lang/rust/pull/151842)*
Ever since rust-lang/rust#103172, `fn_abi_of_instance` might look at a function's body to deduce certain codegen optimization attributes for its indirectly-passed parameters beyond what can be determined purely from its signature (namely today `ArgAttribute::ReadOnly` and `ArgAttribute::CapturesNone`). Since rust-lang/rust#130201, looking at a function's body in this way entails generating, for any coroutine-closures, additional by-move MIR bodies (which aren't represented in the HIR)—but this requires knowing the types of their context and consequently cycles can ensue if such bodies are generated before typeck is complete (such as during CTFE).
Since they have no bearing on the evaluation result, this patch breaks a subquery out from `fn_abi_of_instance`, `fn_abi_of_instance_no_deduced_attrs`, which returns the ABI before such parameter attributes are deduced; and that new subquery is used in CTFE instead (however, since parameter attributes are only deduced in optimized builds, as a performance optimization we avoid calling the original query unless we are performing such a build).
Fixesrust-lang/rust#151748Fixesrust-lang/rust#152497
As explained in the comments, PostAnalysis is good for most IDE things but not method resolution.
This fixes a bug which should not be impacted by this at all - return position impl trait in trait. It is currently lowered to an opaque, while it should be lowered to an anonymous associated type. But today when it is lowered as an opaque, this opaque of course has no definition and will normalize to an error, preventing method resolution on it from succeeding in some cases.
use `minicore` in some `run-make` tests
r? jieyouxu
This manually builds `minicore` in two more `rmake` tests that rolled their own before, and adds a helper for the path of the minicore source. I tried adding a true minicore helper in `run_make_support` but unfortunately the minicore build needs to inherit some (but probably not all) arguments of the final rustc invocation (notably `target` and `target_cpu`), so a one-size-fits-all helper doesn't really work as far as I can see.
For now with 3 uses this is probably fine, but there are probably other `run-make` tests that could use `minicore` but didn't document/simulate that.
follow-up to discussion in https://github.com/rust-lang/rust/pull/153153.
Tweak some of our internal `#[rustc_*]` TEST attributes
I think I might be the one who's used the internal TEST attrs `#[rustc_{dump_predicates,object_lifetime_default,outlives,variance}]` the most in recent times, I might even be the only one. As such I've noticed some recent-ish issues that haven't been fixed so far and which keep bothering me. Moreover I have a longstanding urge to rename several of these attributes which I couldn't contain anymore.
[`#[rustc_*]` TEST attributes](https://rustc-dev-guide.rust-lang.org/compiler-debugging.html#rustc_-test-attributes) are internal attributes that basically allow you to dump the output of specific queries for use in UI tests or for debugging purposes.
1. When some of these attributes were ported over to the new parsing API, their targets were unnecessarily restricted. I've kept encountering these incorrect "attribute cannot be used" errors all the while HIR analysis happily & correctly dumped the requested data below it. I've now relaxed their targets.
2. Since we now have target checking for the internal attributes I figured that it's unhelpful if we still intentionally crashed on invalid targets, so I've got rid of that.
3. I've always been annoyed that most of these (very old) attributes don't contain the word `dump` in their name (rendering their purpose non-obvious) and that some of their names diverge quite a bit from the corresponding query name. I've now rectified that. The new names take longer to type but it's still absolutely acceptable imo.
---
I haven't renamed all of the TEST attributes to follow the `rustc_dump_` scheme since that's quite tedious. If it's okay with you I'd like to postpone that (e.g., `rustc_{def_path,hidden_type…,layout,regions,symbol_name}`).
I've noticed that the parsers for TEST attrs are spread across `rustc_dump.rs`, `rustc_internal.rs` & `test_attrs.rs` which is a bit confusing. Since the new names are prefixed with `rustc_dump_` I've moved their parsers into `rustc_dump.rs` but of course they are still TEST attrs. IIRC, `test_attrs.rs` also contains non-`rustc_`-TEST attrs, so we can't just merge these two files. I guess that'll sort itself out in the future when I tackle the other internal TEST attrs.
r\? Jana || Jonathan
Remove `cycle_fatal` query modifier
This removes the `cycle_fatal` query modifier as it has no effect on its current users.
The default `CycleErrorHandling::Error` mode does the same as `cycle_fatal` when the default impl of `FromCycleError` is used. The return types of queries using `cycle_fatal` however have no specialized `FromCycleError` impl.
Abort after `representability` errors
Doing so results in better error messages and makes the code a bit simpler. Details in individual commits.
r? @oli-obk
Update path separators to be available in const context
Tracking issue: rust-lang/rust#153106
This makes platform-dependent secondary path separators available in const context (ie. at compile time). The platform definitions have also been consolidated behind a common macro to prevent transcription errors, whereas previously they were defined 3-4 times per platform.
### Questions
I've manually verified that this compiles against each platform. It seems like no unit tests should be required for this change; is that correct?
When rewriting assoc type shorthand lowering (`TypeParam::AssocType`), I took into account that if two traits have the same assoc type, even if one is a supertrait of the other, it's an error. However it turns out that assoc type predicates (`Trait<AssocType = Foo>`) uses the same infrastructure, and there it's allowed to specify an ambiguous assoc type when it refers to a sub-trait. So make a distinction between ambiguous assoc type that comes from a supertrait and one that does not, and if it comes from a supertrait, keep the resolved assoc type for cases that need it.
Make `rustc_with_all_queries!` pass query modifiers as named values
This PR is a bold overhaul of how the proc-macro in `rustc_macros::query` passes query modifiers to the callback macros in `rustc_middle` and `rustc_query_impl`.
The existing approach passes modifiers as a list that looks like `[(arena_cache), (no_hash)]`. That style requires a family of helper macros (`if_arena_cache!`, `if_no_hash!`) to check for modifiers when consuming the query list.
This PR changes the proc-macro to instead pass modifiers like this:
```text
{
anon: false,
arena_cache: true,
cache_on_disk: false,
...
}
```
This style allows each of the callback macros to deconstruct the modifier list in a relatively straightforward way, by binding the true/false literals to variables like `$arena_cache:literal`.
One of the big advantages of this style is that we can write things like `#[cfg($arena_cache)]` and `#[cfg(not($arena_cache))]` to select blocks of code, eliminating the need for the `if_arena_cache!` family of helper macros.
In follow-up PRs, we can also try to take advantage of the new modifier style to pass richer information for some modifiers, such as `desc` or `cache_on_disk_if`. That could potentially make it more reasonable to get rid of the `_description_fns` and `_cache_on_disk_if_fns` modules, as proposed in https://github.com/rust-lang/rust/pull/153065.
r? nnethercote
