Don't stop evaluating due to errors before borrow checking
r? @oli-obk
Fix#60005. Follow up to #59903. Blocked on #53708, fixing the ICE in `src/test/ui/consts/match_ice.rs`.
Properly parse '--extern-private' with name and path
It turns out that https://github.com/rust-lang/rust/pull/57586 didn't properly parse `--extern-private name=path`.
This PR properly implements the `--extern-private` option. I've added a new `extern-private` option to `compiletest`, which causes an `--extern-private` option to be passed to the compiler with the proper path.
Part of https://github.com/rust-lang/rust/issues/44663
Add discr_index to multi-variant layouts
We remove the assumption that the discriminant is always field 0, in
preparations for layouts like generators where this is not (always) going to be
the case.
Specifically, upvars are going to go before the discriminant. In theory, it's possible to remove _that_ assumption instead and keep the discriminant at field index 0, but one assumption or the other had to go :)
There is one place I know of in the debuginfo code where we'll still need to remove assumptions that the discriminant is the _only_ field. I was planning on doing this along with the upcoming generator change, which will also include tests that exercise the code changing in this PR.
r? @eddyb
cc @oli-obk
cc @cramertj
rustc_target: factor out common fields of non-Single Variants.
@tmandry and I were discussing ways to generalize the current variants/discriminant layout to allow more fields in the "`enum`" (or another multi-variant types, such as potentially generator state, in the future), shared by all variants, than just the tag/niche discriminant.
This refactor should make it easier to extend multi-variant layouts, as nothing is duplicating anymore between "tagged enums" and "niche-filling enums".
r? @oli-obk
rustc(codegen): uncache `def_symbol_name` prefix from `symbol_name`.
The `def_symbol_name` query was an optimization to avoid recomputing the common part of a symbol name, as only the hash needs to be added to it for each symbol.
However, #57967 will add a new mangling scheme, which doesn't readily support this kind of reuse - while it's plausible, it requires a lot more effort, since you'd have to "symbolically evaluate" mangling, and keep it in a form where the backreference positions can be computed correctly in the final step.
So I want to see how much time we're actually saving with this `def_symbol_name` optimization, nowadays.
cc @michaelwoerister
This commit removes the check that disallows the `#[non_exhaustive]`
attribute from being placed on enum variants and removes the associated
tests.
Further, this commit lowers the visibility of enum variant constructors
when the variant is marked as non-exhaustive.
Type dependent defs wrappers
First of all, forgive me if something would seem lame to you or I offend some rule (although I tried to read through docs), this is my first PR.
Issue: https://github.com/rust-lang/rust/issues/59094
This PR adds 3 helper methods to `TypeckTables`:
* `opt_type_dependent_def`
* `opt_type_dependent_def_id`
* `type_dependent_def_id`
I didn't add `type_dependent_def` as was proposed in the issue simply because it wasn't used anywhere in the code. Only non-option wrapped`type_dependent_defs()[]` accesses were found in clippy which always called `def_id()` on result.
Speaking of clippy, should I open separate PR in its own repo, given it's used as submodule here?
Sry it took me so long, as I said I'm new here and I had tough week :).
Combine input and eval_always query types
Hardcoding `Krate` as a dependency of `eval_always` queries doesn't really make sense if we want to use the query system before HIR lowering / hashing. Without that hardcoding they become pretty much identical to `input` queries, so I combined them to a single type. This will regress the `clean` incremental scenario, but that isn't terribly common.
r? @michaelwoerister
