| Age | Commit message (Collapse) | Author | Lines |
|---|
|
r=GuillaumeGomez
Remove `#[macro_use] extern crate tracing` from rustdoc and rustfmt
A follow-up to #129767 and earlier PRs doing this for `rustc_*` crates.
r? ```@GuillaumeGomez```
|
|
Stop using `ty::GenericPredicates` for non-predicates_of queries
`GenericPredicates` is a struct of several parts: A list of of an item's own predicates, and a parent def id (and some effects related stuff, but ignore that since it's kinda irrelevant). When instantiating these generic predicates, it calls `predicates_of` on the parent and instantiates its predicates, and appends the item's own instantiated predicates too:
https://github.com/rust-lang/rust/blob/acb4e8b6251f1d8da36f08e7a70fa23fc581839e/compiler/rustc_middle/src/ty/generics.rs#L407-L413
Notice how this should result in a recursive set of calls to `predicates_of`... However, `GenericPredicates` is *also* misused by a bunch of *other* queries as a convenient way of passing around a list of predicates. For these queries, we don't ever set the parent def id of the `GenericPredicates`, but if we did, then this would be very easy to mistakenly call `predicates_of` instead of some other intended parent query.
Given that footgun, and the fact that we don't ever even *use* the parent def id in the `GenericPredicates` returned from queries like `explicit_super_predicates_of`, It really has no benefit over just returning `&'tcx [(Clause<'tcx>, Span)]`.
This PR additionally opts to wrap the results of `EarlyBinder`, as we've tended to use that in the return type of these kinds of queries to properly convey that the user has params to deal with, and it also gives a convenient way of iterating over a slice of things after instantiating.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Shrink `TyKind::FnPtr`.
By splitting the `FnSig` within `TyKind::FnPtr` into `FnSigTys` and `FnHeader`, which can be packed more efficiently. This reduces the size of the hot `TyKind` type from 32 bytes to 24 bytes on 64-bit platforms. This reduces peak memory usage by a few percent on some benchmarks. It also reduces cache misses and page faults similarly, though this doesn't translate to clear cycles or wall-time improvements on CI.
r? `@compiler-errors`
|
|
|
|
By splitting the `FnSig` within `TyKind::FnPtr` into `FnSigTys` and
`FnHeader`, which can be packed more efficiently. This reduces the size
of the hot `TyKind` type from 32 bytes to 24 bytes on 64-bit platforms.
This reduces peak memory usage by a few percent on some benchmarks. It
also reduces cache misses and page faults similarly, though this doesn't
translate to clear cycles or wall-time improvements on CI.
|
|
It was barely used, and the places that used it are actually clearer
without it since they were often undoing some of its work. This also
avoids an unnecessary clone of the receiver type and removes a layer of
logical indirection in the code.
|
|
Rustdoc often has to special-case `Self` because it is, well, a special
type of generic parameter (although it also behaves as an alias in
concrete impls). Instead of spreading this special-casing throughout the
code base, create a new variant of the `clean::Type` enum that is for
`Self` types.
This is a refactoring that has almost no impact on rustdoc's behavior,
except that `&Self`, `(Self,)`, `&[Self]`, and other similar occurrences
of `Self` no longer link to the wrapping type (reference primitive,
tuple primitive, etc.) as regular generics do. I felt this made more
sense since users would expect `Self` to link to the containing trait or
aliased type (though those are usually expanded), not the primitive that
is wrapping it. For an example of the change, see the docs for
`std::alloc::Allocator::by_ref`.
|
|
`SelfTy` makes it sound like it is literally the `Self` type, whereas in
fact it may be `&Self` or other types. Plus, I want to use the name
`SelfTy` for a new variant of `clean::Type`. Having both causes
resolution conflicts or at least confusion.
|
|
rustdoc: Cleanup `CacheBuilder` code for building search index
This code was very convoluted and hard to reason about. It is now (I hope) much
clearer and more suitable for both future enhancements and future cleanups.
I'm doing this as a precursor, with no UI changes, to changing rustdoc to
[ignore blanket impls][1] in type-based search.
[1]: https://github.com/rust-lang/rust/pull/128471#discussion_r1699475342
r? ``@notriddle``
|
|
|
|
|
|
The previous commit updated `rustfmt.toml` appropriately. This commit is
the outcome of running `x fmt --all` with the new formatting options.
|
|
|
|
|
|
r=fmease
Add cross-crate precise capturing support to rustdoc
Follow-up to #127632. Fixes #127228.
r? `@fmease`
Tracking:
* https://github.com/rust-lang/rust/issues/123432
|
|
|
|
|
|
This is a very large commit since a lot needs to be changed in order to
make the tests pass. The salient changes are:
- `ConstArgKind` gets a new `Path` variant, and all const params are now
represented using it. Non-param paths still use `ConstArgKind::Anon`
to prevent this change from getting too large, but they will soon use
the `Path` variant too.
- `ConstArg` gets a distinct `hir_id` field and its own variant in
`hir::Node`. This affected many parts of the compiler that expected
the parent of an `AnonConst` to be the containing context (e.g., an
array repeat expression). They have been changed to check the
"grandparent" where necessary.
- Some `ast::AnonConst`s now have their `DefId`s created in
rustc_ast_lowering rather than `DefCollector`. This is because in some
cases they will end up becoming a `ConstArgKind::Path` instead, which
has no `DefId`. We have to solve this in a hacky way where we guess
whether the `AnonConst` could end up as a path const since we can't
know for sure until after name resolution (`N` could refer to a free
const or a nullary struct). If it has no chance as being a const
param, then we create a `DefId` in `DefCollector` -- otherwise we
decide during ast_lowering. This will have to be updated once all path
consts use `ConstArgKind::Path`.
- We explicitly use `ConstArgHasType` for array lengths, rather than
implicitly relying on anon const type feeding -- this is due to the
addition of `ConstArgKind::Path`.
- Some tests have their outputs changed, but the changes are for the
most part minor (including removing duplicate or almost-duplicate
errors). One test now ICEs, but it is for an incomplete, unstable
feature and is now tracked at #127009.
|
|
Now everything that actually affects the type system (i.e., excluding
const blocks, enum variant discriminants, etc.) *should* be using
`ConstArg`.
|
|
|
|
|
|
This will allow lowering const params to a dedicated enum variant, rather
than to an `AnonConst` that is later examined during `ty` lowering.
|
|
|
|
|
|
|
|
rustdoc-json: Better representation of lifetime bounds in where clauses.
As suggested [on zulip][1] (CC `@its-the-shrimp),` there's no need to use `GenericBound` here, as the only bound a lifetime can have is that it outlives other lifetimes.
While we're making breaking changes here, I also renamed it from using "region" to "lifetime", as this is more user-aligned. See [this comment][2] for details.
[1]: https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/.60ItemEnum.3A.3AOpaqueTy.60/near/448871430
[2]: https://github.com/rust-lang/rust/issues/100961#issuecomment-2206565556
r? `@GuillaumeGomez`
|
|
Change return-type-notation to use `(..)`
Aligns the syntax with the current wording of [RFC 3654](https://github.com/rust-lang/rfcs/pull/3654). Also implements rustfmt support (along with making a match exhaustive).
Tracking:
* https://github.com/rust-lang/rust/issues/109417
|
|
As suggested [on zulip][1], there's no need to use `GenericBound` here,
as the only bound a lifetime can have is that it outlives other
lifetimes.
While we're making breaking changes here, I also renamed it from using
"region" to "lifetime", as this is more user-aligned. See [this
comment][2] for details.
[1]: https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/.60ItemEnum.3A.3AOpaqueTy.60/near/448871430
[2]: https://github.com/rust-lang/rust/issues/100961#issuecomment-2206565556
|
|
Implement new effects desugaring
cc `@rust-lang/project-const-traits.` Will write down notes once I have finished.
* [x] See if we want `T: Tr` to desugar into `T: Tr, T::Effects: Compat<true>`
* [x] Fix ICEs on `type Assoc: ~const Tr` and `type Assoc<T: ~const Tr>`
* [ ] add types and traits to minicore test
* [ ] update rustc-dev-guide
Fixes #119717
Fixes #123664
Fixes #124857
Fixes #126148
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Revert "use `tcx.used_crates(())` more" before it reaches beta
There are more open issues caused by #124976 than will be fixed by #125493 alone. The beta cut is soon, so let's revert it and buy some time to analyze and fix these issues in our own time.
fixes https://github.com/rust-lang/rust/issues/125474
fixes https://github.com/rust-lang/rust/issues/125484
fixes https://github.com/rust-lang/rust/issues/125646
fixes https://github.com/rust-lang/rust/issues/125707
fixes #126066
fixes #125934
fixes https://github.com/rust-lang/rust/issues/126021
r? `@petrochenkov`
`@bors` p=1
|
|
This reverts commit eda4a35f365535af72118118a3597edf5a13c12d, reversing
changes made to eb6b35b5bcb3c2a594cb29cd478aeb2893f49d30.
|
|
Unsafe extern blocks
This implements RFC 3484.
Tracking issue #123743 and RFC https://github.com/rust-lang/rfcs/pull/3484
This is better reviewed commit by commit.
|
|
|
|
Currently we have an awkward mix of fallible and infallible functions:
```
new_parser_from_source_str
maybe_new_parser_from_source_str
new_parser_from_file
(maybe_new_parser_from_file) // missing
(new_parser_from_source_file) // missing
maybe_new_parser_from_source_file
source_str_to_stream
maybe_source_file_to_stream
```
We could add the two missing functions, but instead this commit removes
of all the infallible ones and renames the fallible ones leaving us with
these which are all fallible:
```
new_parser_from_source_str
new_parser_from_file
new_parser_from_source_file
source_str_to_stream
source_file_to_stream
```
This requires making `unwrap_or_emit_fatal` public so callers of
formerly infallible functions can still work.
This does make some of the call sites slightly more verbose, but I think
it's worth it for the simpler API. Also, there are two `catch_unwind`
calls and one `catch_fatal_errors` call in this diff that become
removable thanks this change. (I will do that in a follow-up PR.)
|
|
|
