Update library tracking issue template to set S-tracking-unimplemented
This will help people notice the `S-tracking-*` labels, and if the
tracking issue *is* implemented, they can change the label.
Discussed in a `@rust-lang/libs-api` meeting.
r? `@Amanieu`
Instantiate higher-ranked transmute goal w/ placeholders before emitting sub-obligations
This avoids an ICE where we weren't keeping track of bound variables correctly in the `Freeze` obligations we emit for transmute goals. We could use `rebind` instead on that goal, but I think it's better just to instantiate the binder.
Fixes#139538
r? `@lcnr` or reassign
compiletest: Remove the `--logfile` flag
This flag is deprecated in libtest (#134283), and there's no evidence in-tree of this flag actually being passed to compiletest.
For detailed information about test results, bootstrap parses JSON output from compiletest instead (#108659).
As part of my experimental work on removing the libtest dependency from compiletest, it's useful to be able to disconnect libtest functionality that isn't needed.
compiletest maintenance: sort deps and drop dep on `anyhow`
Two changes:
1. Sort compiletest deps alphabetically because it was annoying me (harder to quickly glance what deps compiletest is using).
2. Drop dependency on `anyhow`. There's only one usage of `anyhow`, which is for `with_context` on sth that would immediately panic anyway.
Improve presentation of closure signature mismatch from `Fn` trait goal
Flip the order of "expected" and "found" since that wasn't correct.
Don't present the arguments as a tuple, since it leaves a trailing comma. Instead, just use `fn(arg, arg)`.
Finally, be better with binders since we were just skipping binders.
r? oli-obk or reassign
Fix stack overflow in exhaustiveness due to recursive HIR opaque hidden types
This fixes several spicy non-trivial recursive opaque definitions inferred from HIR typeck, ensuring that they don't cause stack overflows in exhaustiveness code, which currently reveals opaques manually in a way that is not overflow aware (as opposed to something like the normalizer folders).
These should eventually be outright rejected, but today (some) non-trivial recursive opaque definitions are accepted, and changing that requires an FCP, so for now just make sure we don't stack overflow :^)
Fixes https://github.com/rust-lang/rust/issues/139402
r? lcnr
compiletest: Stricter parsing for diagnostic kinds
Non-controversial parts of https://github.com/rust-lang/rust/pull/139427 not requiring many changes in the test suite.
r? ``@jieyouxu``
borrowck typeck children together with their root
This introduces new cycle errors, even with `feature(inline_const_pat)` removed, see the `non-structural-match-types-cycle-err.rs` test.
The new cycle error happens as the layout of `async`-blocks relies on their `optimized_mir`. As that now depends on `mir_borrowck` of its typeck parent, computing the layout of an `async`-block during MIR building, e.g. when evaluating a named `const` pattern. I think there's currently no way to have a named const pattern whose type references an async block while being allowed? cc `@oli-obk` `@RalfJung`
I cannot think of other cases where we currently rely on the MIR of a typeck children while borrowchecking their parent. The crater run came back without any breakage. My work here will prevent any future features which rely on this as we'll get locked into borrowchecking them together as I continue to work on https://github.com/rust-lang/types-team/issues/129, cc `@rust-lang/types.`
r? compiler-errors
This flag is deprecated in libtest, and there's no evidence in-tree of this
flag actually being passed to compiletest.
(For detailed information about test results, bootstrap parses JSON output from
compiletest instead.)
Rollup of 10 pull requests
Successful merges:
- #138676 (Implement overflow for infinite implied lifetime bounds)
- #139024 (Make error message for missing fields with `..` and without `..` more consistent)
- #139098 (Tell LLVM about impossible niche tags)
- #139124 (compiler: report error when trait object type param reference self)
- #139321 (Update to new rinja version (askama))
- #139346 (Don't construct preds w escaping bound vars in `diagnostic_hir_wf_check`)
- #139386 (make it possible to use stage0 libtest on compiletest)
- #139421 (Fix trait upcasting to dyn type with no principal when there are projections)
- #139464 (Allow for reparsing failure when reparsing a pasted metavar.)
- #139490 (Update some comment/docs related to "extern intrinsic" removal)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix trait upcasting to dyn type with no principal when there are projections
#126660 (which I had originally authored, lol) had a subtle bug that is the moral equivalent of #114036, which is that when upcasting from `dyn Principal<Projection = Ty> + AutoTrait` to `dyn AutoTrait`, we were dropping the trait ref for `Principal` but not its projections (if there were any).
With debug assertions enabled, this triggers the assertion I luckily added in a2a0cfe825, but even without debug assertions this is a logical bug since we had a dyn type with just a projection bound but no principal, so it caused a type mismatch.
This does not need an FCP because this should've been covered by the FCP in #126660, but we just weren't testing a case when casting from a `dyn` type with projections 😸Fixes#139418
r? ````@oli-obk```` (or anyone)
make it possible to use stage0 libtest on compiletest
With https://github.com/rust-lang/rust/pull/119899, building the library tree will require a stage 1 compiler. This is because `compiletest` is defined as a `ToolStd` (since https://github.com/rust-lang/rust/pull/68019) in order to use the in-tree library. As a result, https://github.com/rust-lang/rust/pull/119899 makes certain development workflows more difficult as changes on the compiler tree will now require recompiling `compiletest` each time.
This PR allows switching `ToolStd` to `ToolBootstrap` with a simple boolean option in `bootstrap.toml` to allow `compiletest` to use the stage 0 `libtest` instead.
The changes under `src/ci` are clearly intended to make sure that `compiletest` doesn't break during future bootstrap beta bumps.
compiler: report error when trait object type param reference self
Fixes#139082.
Emits an error when `Self` is found in the projection bounds of a trait
object. In type aliases, `Self` has no meaning, so `type A = &'static
dyn B` where `trait B = Fn() -> Self` will expands to `type A = &'static
Fn() -> Self` which is illegal, causing the region solver to bail out
when hitting the uninferred Self.
r? ````@compiler-errors```` ````@fee1-dead````
Tell LLVM about impossible niche tags
I was trying to find a better way of emitting discriminant calculations, but sadly had no luck.
So here's a fairly small PR with the bits that did seem worth bothering:
1. As the [`TagEncoding::Niche` docs](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_abi/enum.TagEncoding.html#variant.Niche) describe, it's possible to end up with a dead value in the input that's not already communicated via the range parameter attribute nor the range load metadata attribute. So this adds an `llvm.assume` in non-debug mode to tell LLVM about that. (That way it can tell that the sides of the `select` have disjoint possible values.)
2. I'd written a bunch more tests, or at least made them parameterized, in the process of trying things out, so this checks in those tests to hopefully help future people not trip on the same weird edge cases, like when the tag type is `i8` but yet there's still a variant index and discriminant of `258` which doesn't fit in that tag type because the enum is really weird.
Make error message for missing fields with `..` and without `..` more consistent
When `..` is not present, we say "missing field `bar` in initializer", but when it is present we say "missing mandatory field `bar`". I don't see why the primary error message should change, b/c the root cause is the same.
Let's harmonize these error messages and instead use a label to explain that `..` is required b/c it's not defaulted.
r? estebank
