| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Enable Rust to use the EHCont security feature of Windows
In the future Windows will enable Control-flow Enforcement Technology (CET aka Shadow Stacks). To protect the path where the context is updated during exception handling, the binary is required to enumerate valid unwind entrypoints in a dedicated section which is validated when the context is being set during exception handling.
The required support for EHCONT Guard has already been merged into LLVM, long ago. This change simply adds the Rust codegen option to enable it.
Relevant LLVM change: https://reviews.llvm.org/D40223
This also adds a new `ehcont-guard` option to the bootstrap config which enables EHCont Guard when building std.
We at Microsoft have been using this feature for a significant period of time; we are confident that the LLVM feature, when enabled, generates well-formed code.
We currently enable EHCONT using a codegen feature, but I'm certainly open to refactoring this to be a target feature instead, or to use any appropriate mechanism to enable it.
|
|
|
|
|
|
|
|
|
|
Stabilize RFC3324 dyn upcasting coercion
This PR stabilize the `trait_upcasting` feature, aka https://github.com/rust-lang/rfcs/pull/3324.
The FCP was completed here: https://github.com/rust-lang/rust/issues/65991#issuecomment-1817552398.
~~And also remove the `deref_into_dyn_supertrait` lint which is now handled by dyn upcasting coercion.~~
Heavily inspired by https://github.com/rust-lang/rust/pull/101718
Fixes https://github.com/rust-lang/rust/issues/65991
|
|
Aka trait_upcasting feature.
And also adjust the `deref_into_dyn_supertrait` lint.
|
|
Queries cleanups
r? `@bjorn3`
|
|
|
|
|
|
|
|
|
|
Remove `feature` from the list of well known check-cfg name
This PR removes `feature` from the list of well known check-cfg.
This is done for multiple reasons:
- Cargo is the source of truth, rustc shouldn't have any knowledge of it
- It creates a conflict between Cargo and rustc when there are no features defined.
In this case Cargo won't pass any `--check-cfg` for `feature` since no feature will ever be passed, but rustc by having in it's list adds a implicit `cfg(feature, values(any()))` which is completely wrong. Having any cfg `feature` is unexpected not allow any `feature` value.
While doing this, I took the opportunity to specialise the diagnostic a bit for the case above.
r? `@petrochenkov`
|
|
`rustc_ast_pretty` cleanups
Some improvements I found while looking at this code.
r? `@fee1-dead`
|
|
And remove the relevant getters on `Compiler` and `Queries`.
|
|
|
|
|
|
In the future Windows will enable Control-flow Enforcement Technology
(CET aka Shadow Stacks). To protect the path where the context is
updated during exception handling, the binary is required to enumerate
valid unwind entrypoints in a dedicated section which is validated when
the context is being set during exception handling.
The required support for EHCONT has already been merged into LLVM,
long ago. This change adds the Rust codegen option to enable it.
Reference:
* https://reviews.llvm.org/D40223
This also adds a new `ehcont-guard` option to the bootstrap config which
enables EHCont Guard when building std.
|
|
|
|
Because the API for `with_position` improved in 0.11 and I want to use
it.
|
|
The search sorting code already sorts by item type discriminant,
putting things with smaller discriminants first. There was
also a special case for sorting keywords and primitives earlier,
and this commit removes it by giving them lower discriminants.
The sorting code has another criteria where items with descriptions
appear earlier than items without, and that criteria has higher
priority than the item type. This shouldn't matter, though,
because primitives and keywords normally only appear in the
standard library, and it always gives them descriptions.
|
|
This computes the same result with less code by computing many of
the old checks at once:
* It won't enter the loop if clength > length, because then the
result of length - clength will be negative and the
loop conditional will fail.
* i + clength will never be greater than length, because it
starts out as i = length - clength, implying that i + clength
equals length, and it only goes down from there.
* The aborted variable is replaced with control flow.
|
|
When building the standard library with Miri, it appears that cargo-miri
does not respect the RUSTFLAGS and even if they did it would be wrong
since they are created for ToolRustc not Std. To avoid errors ignore
RUSTC_HOST_FLAGS for Miri.
|
|
|
|
|
|
|
|
Remove now deprecated target x86_64-sun-solaris.
|
|
r=albertlarsan68
Remove i686-apple-darwin cross-testing
The Xcode SDK no longer ships with 32-bit Intel (i686-apple-darwin) support as of [Xcode 14](https://developer.apple.com/news/upcoming-requirements/?id=06062022a) (related, #112753). On an up-to-date Intel Mac, `x.py test --bless` fails.
r? ``@rust-lang/bootstrap``
|
|
Expand Miri's BorTag GC to a Provenance GC
As suggested in https://github.com/rust-lang/miri/issues/3080#issuecomment-1732505573
We previously solved memory growth issues associated with the Stacked Borrows and Tree Borrows runtimes with a GC. But of course we also have state accumulation associated with whole allocations elsewhere in the interpreter, and this PR starts tackling those.
To do this, we expand the visitor for the GC so that it can visit a BorTag or an AllocId. Instead of collecting all live AllocIds into a single HashSet, we just collect from the Machine itself then go through an accessor `InterpCx::is_alloc_live` which checks a number of allocation data structures in the core interpreter. This avoids the overhead of all the inserts that collecting their keys would require.
r? ``@RalfJung``
|
|
Remove `--check-cfg` checking of command line `--cfg` args
Back in https://github.com/rust-lang/rust/pull/100574 we added to the `unexpected_cfgs` lint the checking of `--cfg` CLI arguments and emitted unexpected names and values for them.
The implementation works as expected, but it's usability in particular when using it in combination with Cargo+`RUSTFLAGS` as people who set `RUSTFLAGS=--cfg=tokio_unstable` (or whatever) have `unexpected_cfgs` warnings on all of their crates is debatable. ~~To fix this issue this PR proposes that we split the CLI argument checking into it's own separate allow-by-default lint: `unexpected_cli_cfgs`.~~
~~This has the advantage of letting people who want CLI warnings have them (although not by default anymore), while still linting on every unexpected cfg name and values in the code.~~
After some discussion with the Cargo team ([Zulip thread](https://rust-lang.zulipchat.com/#narrow/stream/246057-t-cargo/topic/check-cfg.20and.20RUSTFLAGS.20interaction)) and member of the compiler team (see below), I propose that we follow the suggestion from `@epage:` never check `--cfg` arguments, but still reserve us the possibility to do it later.
We would still lint on unexpected cfgs found in the source code no matter the `--cfg` args passed. This mean reverting https://github.com/rust-lang/rust/pull/100574 but NOT https://github.com/rust-lang/rust/pull/99519.
r? `@petrochenkov`
|
|
r=GuillaumeGomez
rustdoc-search: add support for traits and associated types
# Summary
Trait associated type queries work in rustdoc's type driven search. The data is included in the search-index.js file, and the queries are designed to "do what I mean" when users type them in, so, for example, `Iterator<Item=T> -> Option<T>` includes `Iterator::next` in the SERP[^SERP], and `Iterator<T> -> Option<T>` also includes `Iterator::next` in the SERP.
[^SERP]: search engine results page
## Sample searches
* [`iterator<Item=T>, fnmut -> T`][iterreduce]
* [`iterator<T>, fnmut -> T`][iterreduceterse]
[iterreduce]: http://notriddle.com/rustdoc-html-demo-5/associated-types/std/index.html?search=iterator%3CItem%3DT%3E%2C%20fnmut%20-%3E%20T&filter-crate=std
[iterreduceterse]: http://notriddle.com/rustdoc-html-demo-5/associated-types/std/index.html?search=iterator%3CT%3E%2C%20fnmut%20-%3E%20T&filter-crate=std
# Motivation
My primary motivation for working on search.js at all is to make it easier to use highly generic APIs, like the Iterator API. The type signature describes these functions pretty well, while the names are almost arbitrary.
Before this PR, type bindings were not consistently included in search-index.js at all (you couldn't find Iterator::next by typing in its function signature) and you couldn't explicitly search for them. This PR fixes both of these problems.
# Guide-level explanation
*Excerpt from [the Rustdoc book](http://notriddle.com/rustdoc-html-demo-5/associated-types/rustdoc/read-documentation/search.html), included in this PR.*
> Function signature searches can query generics, wrapped in angle brackets, and traits will be normalized like types in the search engine if no type parameters match them. For example, a function with the signature `fn my_function<I: Iterator<Item=u32>>(input: I) -> usize` can be matched with the following queries:
>
> * `Iterator<Item=u32> -> usize`
> * `Iterator<u32> -> usize` (you can leave out the `Item=` part)
> * `Iterator -> usize` (you can leave out iterator's generic entirely)
> * `T -> usize` (you can match with a generic parameter)
>
> Each of the above queries is progressively looser, except the last one would not match `dyn Iterator`, since that's not a type parameter.
# Reference-level explanation
Inside the angle brackets, you can choose whether to write a name before the parameter and the equal sign. This syntax is called [`GenericArgsBinding`](https://doc.rust-lang.org/reference/paths.html#paths-in-expressions) in the Rust Reference, and it allows you to constrain a trait's associated type.
As a convenience, you don't actually have to put the name in (Rust requires it, but Rustdoc Search doesn't). This works about the same way unboxing already works in Search: the terse `Iterator<u32>` is a match for `Iterator<Item=u32>`, but the opposite is not true, just like `u32` is a match for `Iterator<u32>`.
When converting a trait method for the search index, the trait is substituted for `Self`, and all associated types are bound to generics. This way, if you have the following trait definition:
```rust
pub trait MyTrait {
type Output;
fn method(self) -> Self::Output;
}
```
The following queries will match its method:
* `MyTrait<Output=T> -> T`
* `MyTrait<T> -> T`
* `MyTrait -> T`
But these queries will not match it:
* <i>`MyTrait<Output=u32> -> u32`</i>
* <i>`MyTrait<Output> -> Output`</i>
* <i>`MyTrait -> MyTrait::Output`</i>
# Drawbacks
It's a little bit bigger:
```console
$ du before/search-index1.74.0.js after/search-index1.74.0.js
4020 before/search-index1.74.0.js
4068 after/search-index1.74.0.js
```
# Rationale and alternatives
I don't want to just not do this. On it's own, it's not terribly useful, but in addition to searching by normal traits, this is also intended as a desugaring target for closures. That's why it needs to actually distinguish the two: it allows the future desugaring to distinguish function output and input.
The other alternative would be to not allow users to leave out the name, so `iterator<u32>` doesn't work. That would be unfortunate, because mixing up which ones have out params and which ones are plain generics is an easy enough mistake that the Rust compiler itself helps people out with it.
# Prior art
* <http://neilmitchell.blogspot.com/2020/06/hoogle-searching-overview.html>
The current Rustdoc algorithm, both before this PR and after it, has a fairly expensive matching algorithm over a fairly simple file format. Luckily, we aren't trying to scale to all of crates.io, so it's usable, but it's not great when I throw it at docs.servo.org
# Unresolved questions
Okay, but *how do we want to handle closures?* I know the system will desugar `FnOnce(T) -> U` into `trait:FnOnce<Output=U, primitive:tuple<T>>`, but what if I don't know what trait I'm looking for? This PR can merge with nothing, but it'd be nice to have a plan.
Specifically, how should the special form used to handle all varieties of basic callable: primitive:fn (function pointers), and trait:Fn, trait:FnOnce, and trait:FnMut should all be searchable using a single syntax, because I'm always forgetting which one is used in the function I'm looking for.
The essential question is how closely we want to copy Rust's own syntax. The tersest way to expression Option::map might be:
Option<T>, (T -> U) -> Option<U>
That's the approach I would prefer, but nobody's going to attempt it without being told, so maybe this would be better?
Option<T>, (fn(T) -> U) -> Option<U>
It does require double parens, but at least it's mostly unambiguous. Unfortunately, it looks like the syntax you'd use for function pointers, implying that if you specifically wanted to limit your search to function pointers, you'd need to use `primitive:fn(T) -> U`. Then again, searching is normally case-insensitive, so you'd want that anyway to disambiguate from `trait:Fn(T) -> U`.
# Future possibilities
## This thing really needs a ranking algorithm
That is, this PR increases the number of matches for some type-based queries. They're usually pretty good matches, but there's still more of them, and it's evident that if you have two functions, `foo(MyTrait<u8>)` and `bar(MyTrait<Item=u8>)`, if the user typed `MyTrait<u8>` then `foo` should show up first.
A design choice that these PRs have followed is that adding more stuff to the search query always reduces the number of functions that get matched. The advantage of doing it that way is that you can rank them by just counting how many atoms are in the function's signature (lowest score goes on top). Since it's impossible for a matching function to have fewer atoms than the search query, if there's a function with exactly the same set of atoms in it, then that'll be on top.
More complicated ranking algos tend to penalize long documents anyway, if the [distance metrics](https://www.benfrederickson.com/distance-metrics/?utm_source=flipboard&utm_content=other) I found through [Flipboard](https://flipboard.com/`@arnie0426/building-recommender-systems-nvue3iqtgrn10t45)` (and postgresql's `ts_rank_cd`) are anything to go by. Real-world data sets tend to have weird outliers, like they have God Functions with zillions of arguments of all sorts of types, and Rustdoc ought to put such a function at the bottom.
The other natural choice would be interleaving with `unifyFunctionTypes` to count the number of unboxings and reorderings. This would compute a distance function, and would do a fine job of ranking the results, as [described here](https://ndmitchell.com/downloads/slides-hoogle_finding_functions_from_types-16_may_2011.pdf) by the Hoogle dev, but is more complicated than it sounds. The current algorithm returns when it finds a result that *exists at all*, but a distance function should find an *optimal solution* to find the smallest sequence of edits.
## This could also use a benchmark suite and some optimization
This approach also lends itself to layering a bloom filter in front of the backtracking unification engine.
* At load time, hash the typeNameIdMap ID for each atom and set the matching entry in a fixed-size byte array for each function to 1. Call it `fnType.bloomFilter`
* At search time, do the same for the atoms in the query (excluding special forms like `[]` that can match more than one thing). Call it `parsedQuery.bloomFilter`
* For each function, `if (fnType.bloomFilter | (~parsedQuery.bloomFilter) !== ~0) { return false; }`
There's also room to optimize the unification engine itself, by using stacks and persistent data structures instead of copying arrays around, or by using hashing instead of linear scans (the current algorithm was rewritten from one that tried to do that, but was too much to fit in my head and had a bunch of bugs). The advantage of Just Backtracking Better over the bloom filter is that it doesn't require the engine to retain any special algebraic properties.
But, first, we need a set of benchmarks to be able to judge if such a thing will actually help.
## Referring to associated types by path
*I don't want to implement this one, but if I did, this is how I'd do it.*
In Rust, this is represented by a structure called a qualified path, or QPath. They look like this:
<Self as Iterator>::Item
<F as FnOnce>::Output
They can also, if it's unambiguous, use a plain path and just let the system figure it out:
Self::Item
F::Output
In Rustdoc Type-Driven Search, we don't want to force people to be unambiguous. Instead, we should try *all reasonable interpretations*, return results whenever any of them match, and let users make their query more specific if too many results are matches.
To enable associated type path searches in Rustdoc, we need to:
1. When lowering a trait method to a search-index.js function signature, Self should be explicitly represented as a generic argument. It should always be assigned `-1`, so that if the user uses `Self` in their search query, we can ensure it always matches the real Self and not something else. Any functions that don't *have* a Self should drop a `0` into the first position of the where clause, to express that there isn't one and reserve the `-1` position.
* Reminder: generics are negative, concrete types are positive, and zero is a reserved sentinel.
* Right now, `Iterator::next` is lowered as if it were `fn next<T>(self: Iterator<Item=T>) -> Option<T>`.
It should become `fn next<Self, T>(self: Self) -> Option<T> where Self: Iterator<Item=T>` instead.
3. Add another backtracking edge to the unification engine, so that when the user writes something like `some::thing`, the interpretation where `some` is a module and `thing` is a standalone item becomes one possible match candidate, while the interpretation where `some` is a trait and `thing` is an associated type is a separate match candidate. The backtracking engine is basically powerful enough to do this already, since unboxing generic type parameters into their traits already requires the ability to do this kind of thing.
* When interpreting `some::thing` where `some` is a trait and `thing` is an associated type, it should be treated equivalently to `<self as some>::thing`. If you want to bind it to some generic parameter other than `Self`, you need to explicitly say so.
* If no trait called `some` actually exists, treat it as a generic type parameter instead. Track every trait mentioned in the current working function signature, and add a match candidate for each one.
* A user that explicitly wants the trait-associated-type interpretation could write a qpath (like `<self as trait>::type`), and a user that explicitly wants the module-item interpretation should use an item type filter (like `struct:module::type`).
4. To actually do the matching, maintain a `Map<(QueryGenericParamId, TraitId), FnGenericParamId>` alongside the existing `Map<QueryGenericParamId, FnGenericParamId>` that is already used to handle plain generic parameters. This works, because, when a trait function signature is lowered to search-index.js, the `rustdoc` backend always generates an FnGenericParamId for every trait associated type it sees mentioned in the function's signature.
5. Parse QPaths. Specifically,
* QueryElem adds three new fields. `isQPath` is a boolean flag, and `traitNameId` contains an entry for `typeNameIdMap` corresponding to the trait part of a qpath, and `parentId` may contain either a concrete type ID or a negative number referring to a generic type parameter. The actual `id` of the query elem will always be a negative number, because this is essentially a funny way to add a generic type constraint.
* If it's a QPath, then both of those IDs get filled in with the respective parts of the map. The unification engine will check the where clause to ensure the trait actually applies to the generic parameter in question, will check the type parameter constraint, and will add a mapping to `mgens` recording this as a solution.
* If it's just a regular path, then `isQPath` is false, and the parser will fill in both `traitNameId` and `parentId` based on the same path. The unification engine, seeing isQPath is false and that these IDs were filled in, will try all three solutions: the path might be part of a concrete type name, or it might be referring to a trait, or it might be referring to a generic type parameter.
### Why not implement QPath searches?
I'm not sure if anybody really wants to write such complicated queries. You can do a pretty good job of describing the generic functions in the standard library without resorting to FQPs.
These two queries, for example, would both match the Iterator::map function if we added support for higher order function queries and a rule that allows a type to match its *notable traits*.
// I like this version, because it's identical to how `Option::map` would be written.
// There's a reason why Iterator::map and Option::map have the same name.
Iterator<T>, (T -> U) -> Iterator<U>
// This version explicitly uses the type parameter constraints.
Iterator<Item=T>, (T -> U) -> Iterator<Item=U>
If I try to write this one using FQP, however, the results seem worse:
// This one is less expressive than the versions that don't use associated type paths.
// It matches `Iterator::filter`, while the above two example queries don't.
Iterator, (Iterator::Item -> Iterator::Item) -> Iterator
// This doesn't work, because the return type of `Iterator::map` is not a generic
// parameter with an `Iterator` trait bound. It's a concrete type that
// implements `Iterator`. Return-Position-Impl-Trait is the same way.
//
// There's a difference between something like `map`, whose return value
// implements Iterator, and something like `collect`, where the caller
// gets to decide what the concrete type is going to be.
//Self, (Self::Item -> I::Item) -> I where Self: Iterator, I: Iterator
// This works, but it seems subjectively ugly, complex, and counterintuitive to me.
Self, (<Self as Iterator>::Item -> T) -> Iterator<Item=T>
|
|
Required because spdx-rs 0.5.3 added support for SPDX 2.3 documents and made these fields optional.
|
|
|
|
Implemented a new flag, `--with-debug-assertions` on compiletest to pass the stdlib debug
assertion status from bootstrap.
Signed-off-by: onur-ozkan <work@onurozkan.dev>
|
|
Rollup of 7 pull requests
Successful merges:
- #117790 (CFI: Add missing use core::ffi::c_int)
- #118059 (Explicitly unset $CARGO for compiletest)
- #118081 (`rustc_ty_utils` cleanups)
- #118094 (feat: specialize `SpecFromElem` for `()`)
- #118097 (Update books)
- #118115 (Fix occurrences of old fn names in comment and tracing)
- #118121 (`rustc_hir` cleanups)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
Update books
## rust-lang/book
2 commits in 5b6c1ceaa62ecbd6caef08df39b33b3938e99deb..71352deb20727b4dda9ebfe8182709d5bf17dfea
2023-11-09 14:49:45 UTC to 2023-11-09 14:49:16 UTC
- Fixed 'Devtools' link (rust-lang/book#3770)
- Fix mdBook links (rust-lang/book#3769)
## rust-lang/rust-by-example
7 commits in 311b84962016b28c75525c86e7b3f49fd9101a39..a6581246f96837113968c02187db24f742af3908
2023-11-18 21:45:20 UTC to 2023-11-07 22:32:53 UTC
- rename `y` to `_y` to get the correct compile error (rust-lang/rust-by-example#1769)
- fix test name in cargo/test.md (rust-lang/rust-by-example#1768)
- Various minor edits for typo fixes, formatting fixes, and clarifications (rust-lang/rust-by-example#1765)
- Update closures.md to correct a typo (rust-lang/rust-by-example#1763)
- Link to the Bulgarian translation (rust-lang/rust-by-example#1764)
- Fix asm example explanation for `inlateout` usage (22.1 Inline Assembly) (rust-lang/rust-by-example#1766)
- Update index.md: Added descriptions for the 'leftover' points (rust-lang/rust-by-example#1767)
## rust-lang/rustc-dev-guide
3 commits in 77dbe5782b2488af3bb489ad702eaff438f465bf..ddb8b1309f9e905804cea1e248a4572fed6b464b
2023-11-18 21:08:13 UTC to 2023-11-08 14:43:50 UTC
- Add link for unsize.md (rust-lang/rustc-dev-guide#1825)
- Fix typo in contribution walkthrough (rust-lang/rustc-dev-guide#1824)
- Update documentation for coverage tests (rust-lang/rustc-dev-guide#1823)
|
|
Explicitly unset $CARGO for compiletest
Some UI tests trigger behavior in rustc where it reads $CARGO and changes behavior if it exists. To make the tests work that rely on it not being set, make sure it is not set.
By default, this is not set, but people may do weird hacks that cause it to be set.
closes #118058
|
|
Add `$message_type` field to distinguish json diagnostic outputs
Currently the json-formatted outputs have no way to unambiguously determine which kind of message is being output. A consumer can look for specific fields in the json object (eg "message"), but there's no guarantee that in future some other kind of output will have a field of the same name.
This PR adds a `"type"` field to add json outputs which can be used to unambiguously determine which kind of output it is. The mapping is:
`diagnostic`: regular compiler diagnostics
`artifact`: artifact notifications
`future_incompat`: Future incompatibility report
`unused_extern`: Unused crate warnings/errors
This matches the "internally tagged" representation for serde enums.
|
|
|
|
When we encounter a function with a return type that has an anonymous
lifetime with no argument to borrow from, besides suggesting the
`'static` lifetime we now also suggest changing the arguments to be
borrows or changing the return type to be an owned type.
```
error[E0106]: missing lifetime specifier
--> $DIR/variadic-ffi-6.rs:7:6
|
LL | ) -> &usize {
| ^ expected named lifetime parameter
|
= help: this function's return type contains a borrowed value, but there is no value for it to be borrowed from
help: consider using the `'static` lifetime, but this is uncommon unless you're returning a borrowed value from a `const` or a `static`
|
LL | ) -> &'static usize {
| +++++++
help: instead, you are more likely to want to change one of the arguments to be borrowed...
|
LL | x: &usize,
| +
help: ...or alternatively, to want to return an owned value
|
LL - ) -> &usize {
LL + ) -> usize {
|
```
Fix #85843.
|
|
Implement all 16 AVX compare operators for 128-bit SIMD vectors
`_mm_cmp_{ss,ps,sd,pd}` functions are AVX functions that use `llvm.x86.sse{,2}.` prefixed intrinsics, so they were "accidentally" partially implemented when SSE and SSE2 intrinsics were implemented.
The 16 AVX compare operators are now implemented and tested.
|
|
|
|
`_mm_cmp_{ss,ps,sd,pd}` functions are AVX functions that use `llvm.x86.sse{,2}` prefixed intrinsics, so they were "accidentally" partially implemented when SSE and SSE2 intrinsics were implemented.
The 16 AVX compare operators are now implemented and tested.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Rollup of 8 pull requests
Successful merges:
- #117828 (Avoid iterating over hashmaps in astconv)
- #117832 (interpret: simplify handling of shifts by no longer trying to handle signed and unsigned shift amounts in the same branch)
- #117891 (Recover `dyn` and `impl` after `for<...>`)
- #117957 (if available use a Child's pidfd for kill/wait)
- #117988 (Handle attempts to have multiple `cfg`d tail expressions)
- #117994 (Ignore but do not assume region obligations from unifying headers in negative coherence)
- #118000 (Make regionck care about placeholders in outlives components)
- #118068 (subtree update cg_gcc 2023/11/17)
r? `@ghost`
`@rustbot` modify labels: rollup
|
