Unimplement unsized_locals
Implements https://github.com/rust-lang/compiler-team/issues/630
Tracking issue here: https://github.com/rust-lang/rust/issues/111942
Note that this just removes the feature, not the implementation, and does not touch `unsized_fn_params`. This is because it is required to support `Box<dyn FnOnce()>: FnOnce()`.
There may be more that should be removed (possibly in follow up prs)
- the `forget_unsized` function and `forget` intrinsic.
- the `unsized_locals` test directory; I've just fixed up the tests for now
- various codegen support for unsized values and allocas
cc ``@JakobDegen`` ``@oli-obk`` ``@Noratrieb`` ``@programmerjake`` ``@bjorn3``
``@rustbot`` label F-unsized_locals
Fixesrust-lang/rust#79409
Delay replacing escaping bound vars in `FindParamInClause`
By uplifting the `BoundVarReplacer`, which is used by (e.g.) normalization to replace escaping bound vars that are encountered when folding binders, we can use a similar strategy to delay the instantiation of a binder's contents in the `FindParamInClause` used by the new trait solver.
This should alleviate the recently added requirement that `Binder<T>: TypeVisitable` only if `T: TypeFoldable`, which was previously required b/c we were calling `enter_forall` so that we could structurally normalize aliases that we found within the predicates of a param-env clause.
r? lcnr
add `extern "custom"` functions
tracking issue: rust-lang/rust#140829
previous discussion: https://github.com/rust-lang/rust/issues/140566
In short, an `extern "custom"` function is a function with a custom ABI, that rust does not know about. Therefore, such functions can only be defined with `#[unsafe(naked)]` and `naked_asm!`, or via an `extern "C" { /* ... */ }` block. These functions cannot be called using normal rust syntax: calling them can only be done from inline assembly.
The motivation is low-level scenarios where a custom calling convention is used. Currently, we often pick `extern "C"`, but that is a lie because the function does not actually respect the C calling convention.
At the moment `"custom"` seems to be the name with the most support. That name is not final, but we need to pick something to actually implement this.
r? `@traviscross`
cc `@tgross35`
try-job: x86_64-apple-2
Tracking the old name of renamed unstable library features
This PR resolves the first problem of rust-lang/rust#141617 : tracking renamed unstable features. The first commit is to add a ui test, and the second one tracks the changes. I will comment on the code for clarification.
r? `@jdonszelmann`
There have been a lot of PR's reviewed by you lately, thanks for your time!
cc `@jyn514`
Remove check_mod_loops query and run the checks per-body instead
This analysis is older than my first rustc contribution I believe. It was never querified. Ideally we'd merge it into the analysis happening within typeck anyway (typeck just uses span_delayed_bug instead of erroring), but I didn't want to do that within this PR that also moves things around and subtly changes diagnostic ordering.
Remove CollectItemTypesVisitor
I always felt like we were very unnecessarily walking the HIR, let's see if perf agrees
There is lots to ~~improve~~ consolidate further here, as we still have 3 item wfchecks:
* check_item (matching on the hir::ItemKind)
* actually doing trait solver based checks (by using HIR spans)
* lower_item (matching on the hir::ItemKind after loading it again??)
* just ensure_ok-ing a bunch of queries
* check_item_type (matching on DefKind)
* some type based checks, mostly ensure_ok-ing a bunch of queries
fixesrust-lang/rust#121429
Limit the size of cgu names when using the `-Zhuman-readable-cgu-name…
…s` option
Prior to this change, cgu names could be generated which would result in filenames longer than the limit imposed by the OS.
Rollup of 11 pull requests
Successful merges:
- rust-lang/rust#141890 (Add link to correct documentation in htmldocck.py)
- rust-lang/rust#141932 (Fix for async drop inside async gen fn)
- rust-lang/rust#141960 (Use non-2015 edition paths in tests that do not test for their resolution)
- rust-lang/rust#141968 (Run wfcheck in one big loop instead of per module)
- rust-lang/rust#141969 (Triagebot: Remove `assign.users_on_vacation`)
- rust-lang/rust#141985 (Ensure query keys are printed with reduced queries)
- rust-lang/rust#141999 (Visit the ident in `PreciseCapturingNonLifetimeArg`.)
- rust-lang/rust#142005 (Change `tag_field` to `FieldIdx` in `Variants::Multiple`)
- rust-lang/rust#142017 (Fix incorrect use of "recommend" over "recommended")
- rust-lang/rust#142024 (Don't refer to 'this tail expression' in expansion.)
- rust-lang/rust#142025 (Don't refer to 'local binding' in extern macro.)
r? `@ghost`
`@rustbot` modify labels: rollup
Change `tag_field` to `FieldIdx` in `Variants::Multiple`
It was already available as a generic parameter anyway, and it's not like we'll ever put a tag in the 5-billionth field.
This is a first part of pulling smaller pieces out of rust-lang/rust#138759, so
r? workingjubilee
Ensure query keys are printed with reduced queries
Using `-Z query-dep-graph` and debug assertions leads to an ICE that was originally discovered in rust-lang/rust#141700:
> This isn't an incremental bug per se, but instead a bug that has to do with debug printing query keys when debug assertions and `-Z query-dep-graph` is enabled. We end up printing a const (b/c we're using generic const args here) whose debug printing for -Z query-dep-graph requires invoking the same query cyclically 😃
>
> I've pushed a commit which should fix this.
This isn't related to the standard library changes, but instead b/c it seems to be the first usage of `feature(adt_const_params)` in the standard library that ends up being triggered in incremental tests.
r? oli-obk
Run wfcheck in one big loop instead of per module
Maybe we can merge this big loop in the future with the `par_hir_body_owners` call below and run typeck only on items that didn't fail wfcheck. For now let's just see if perf likes it, as it by itself should be beneficial to parallel rustc
Deconstruct values in the THIR visitor
Hi! I am a beginner rust developer.
I'm trying to solve your problem rust-lang/rust#141849
I see that 2 files need to be corrected, so I’m starting with a simpler step, `compiler/rustc_middle/src/thir/visit.rs`
r? `@krikera`
Decouple "reporting in deps" from `FutureIncompatibilityReason`
The reason should just be it -- the reason. It never felt right to me that it was also responsible for whatever we include the warning in cargo's reports.
It gets especially unruly if you want to add non-`FutureReleaseError*` warnings which are included in the reports.
I just added a field to `FutureIncompatibleInfo` to control whatever the diagnostic is included in the cargo's reports.
