rustdoc-json: Refractor and document Id's
Closes#133780
While working on documenting Id's, I realized alot of the way they were generated was weird and unnecessary. Eg:
1. The fully uninterned id type was `(FullItemId, Option<FullItemId>)`, meaning it wasn't actually full!
2. None of the extra fields in `Option<FullItemId>` would ever be used
3. `imported_item_id` was a `rustdoc_json_types::Id` instead of a simpler `DefId`.
I believe the new implementation still covers all the same cases, but in a more principled way (and explaining why each piece is needed).
This was written to be reviewed commit-by-commit, but it might be easier to review all at once if you're not interested in tracking how the original code became the final code.
cc ``@its-the-shrimp``
r? ``@fmease``
The place previously used here was that of the temporary holding the
reference returned by `Deref::deref` or `DerefMut::deref_mut`. However,
since the inner pattern of `deref!(inner)` expects the deref-target type
itself, this would ICE when that type was inspected (e.g. by the EUV
case for slice patterns). This adds a deref projection to fix that.
Since current in-tree consumers of EUV (upvar inference and clippy)
don't care about Rvalues, the place could be simplified to
`self.cat_rvalue(pat.hir_id, self.pat_ty_adjusted(subpat)?)` to save
some cycles. I personally find EUV to be a bit fragile, so I've opted
for pedantic correctness. Maybe a `HACK` comment would suffice though?
This means that things like `<usize as Step>::forward_unchecked` and `<PartialOrd for f32>::le` will inline even if we've already done a bunch of inlining to find the calls to them.
Do not register `Self: AutoTrait` when confirming auto trait (in old solver)
Every built-in auto impl for a trait goal like `Ty: Auto` immediately registers another obligation of `Ty: Auto` as one of its nested obligations, leading to us stressing the cycle detection machinery a lot more than we need to. This is because all traits have a `Self: Trait` predicate.
To fix this, remove the call to `impl_or_trait_obligations` in `vtable_auto_impl`, since auto traits do not have where clauses.
r? lcnr
The lint for function calls was previously restricted to functions
taking exactly one argument. This was not documented.
Generalizing the lint to an arbitrary number of arguments in the
function call requires special casing some macro expansions from the
standard library. Macros such as `panic!()` or `assert_eq!()` exist
since Rust 1.0.0, but modern stdlib expand those macros into calls to
functions introduced in later Rust versions. While it is desirable to
lint code inside macros, using MSRV-incompatible functions coming from
`core` in macro expansions has been special-cased to not trigger this
lint.
Also, code coming from compiler desugaring may contain function calls
(for example, `a..=b` is now desugared into `RangeInclusive::new(a, b)`.
Those should not be linted either as the compiler is allowed to use
unstable function calls.
Fix#14212
changelog: [`incompatible_msrv`]: lint function calls with any argument
count
`uclibc` is not an environment understood by LLVM, it is only a concept
in Clang that can be selected with `-muclibc` (it affects which dynamic
linker is passed to the static linker's `-dynamic-linker` flag).
In fact, using `uclibcgnueabi`/`uclibc` is actively harmful, as it
prevents LLVM from seeing that the target is gnu-like; we should use
`gnueabi`/`gnu` directly instead.
In LLVM v9, lld has supported @response-file
LLVM v9 was released on 2019-09-19.
And the check was added back to 2018-03-14 (1.26.0) via 04442af18b.
It has been more than five years, and we ship our own lld regardlessly.
This should be happily removed.
See also:
* <bb12396f91>
* <https://reviews.llvm.org/D63024>
Calculate predecessor count directly
Avoid allocating a vector of small vectors merely to determine how many
predecessors each basic block has.
Additionally use u8 and saturating operations. The pass only needs to
distinguish between [0..1] and [2..].
Alot of the current id handling is weird and unnecessary. e.g:
1. The fully uninterned id type was (FullItemId, Option<FullItemId>)
meaning it wasn't actually full!
2. None of the extra fields in Option<FullItemId> would ever be used
3. imported_item_id was a rustdoc_json_types::Id instead of a simpler
DefId
This commit removes the unnessessary complexity, and documents where the
remaining complexity comes from.
Co-authored-by: León Orell Valerian Liehr <me@fmease.dev>
The targets used the plain `$ARCH` triple, which LLVM normalizes to
`$ARCH-unknown-unknown`, which is inconsistent with the the other
VxWorks targets which all use `$ARCH-unknown-linux-gnu$ABI`.
I want to work on this in a followup commit, so in this commit I make it
self-contained. Contains no code changes, all functions are defined
exactly as they were in conversions.rs.
This is more useful than `allow` as compiler will force us to remove rules
that are no longer valid (we already got 2 of them in this change).
Signed-off-by: onur-ozkan <work@onurozkan.dev>
Use sa_sigaction instead of sa_union.__su_sigaction for AIX
Revert test cases to use `sa_sigaction` instead of `sa_union.__su_sigaction`, now that the `libc` crate implementation for AIX defines `sa_sigaction` as a direct member of `struct sigaction`, aligning it with implementations on other similar platforms. ([[AIX] Use sa_sigaction instead of the union](https://github.com/rust-lang/libc/pull/4250)).
