Improve the help message for an invalid calling convention
Fixes https://github.com/rust-lang/rust/issues/93601
I mostly followed the suggestions of `@nagisa` in that issue, ~~however, I wasn't sure how to check stability for the suggestion of "Do not suggest CCs that cannot be used due to them being unstable and feature not being enabled", so I did not implement that point.~~
I haven't contributed to rustc much, please feel free to point out suggestions! For example, the `.map(|s| Symbol::intern(s)).collect::<Vec<_>>()` seems pretty gross performance-wise, but maybe that's OK in error reporting code.
rustdoc: remove no-op CSS `.location:empty { border: none }`
This rule was added in 2bb2a2975f to remove a border placed around the location when it's empty. That rule was removed in 6a5f8b1aef, so this rule does nothing.
Extend const_convert with const {FormResidual, Try} for ControlFlow.
Very small change so I just used the existing `const_convert` feature flag. #88674
Newly const API:
```
impl<B, C> const ops::Try for ControlFlow<B, C>;
impl<B, C> const ops::FromResidual for ControlFlow<B, C>;
```
`@usbalbin` I hope it is ok that I added to your feature.
Const unification is already infallible, remove the error handling logic
r? `@lcnr`
is this expected to be used in the future? Right now it is dead code.
rustdoc: remove no-op CSS `.content .item-info { position: relative }`
This rule was added to help position the marker line in 110e7270ab, which was a `position: absolute` pseudo-element that relied on its parent to put it in the right spot. (it was changed from a line to an arrow in 1ffb9cf8d7, then a different arrow in ae3a53ff58).
The arrow was removed in 73d0f7c7b6, so the `relative` position is no longer necessary.
rustdoc: clean up line numbers on code examples
* First commit switches from `display: inline-flex; width: 100%` to `display: flex`.
`display: inline-flex` was used as part of e961d397ca, the original commit that added these line numbers. Does anyone know why it was done this way?
* Second commit makes it so that toggling this checkbox will update the page in real time, just like changing themes does.
Preview: https://notriddle.com/notriddle-rustdoc-test/line-numbers/std/vec/struct.Vec.html
This rule was added in 2bb2a2975f to remove a
border placed around the location when it's empty. That rule was removed in
6a5f8b1aef, so this rule does nothing.
Inline SyntaxContext in both encoded span representation.
The current interned representation for spans does not use the `ctxt_or_zero: u16` field. This PR proposes to use this field to store the `SyntaxContext` of the interned span instead. When `ctxt_or_zero` and the interned span's `ctxt` don't match, the inlined one takes precedence.
This allows to implement `Span::ctxt` and `Span::with_ctxt` with much less probability to access the interner. Those functions are used a lot for hygiene, so this may be worth it.
Rollup of 8 pull requests
Successful merges:
- #101598 (Update rustc's information on Android's sanitizers)
- #102036 (Remove use of `io::ErrorKind::Other` in std)
- #102037 (Make cycle errors recoverable)
- #102069 (Skip `Equate` relation in `handle_opaque_type`)
- #102076 (rustc_transmute: fix big-endian discriminants)
- #102107 (Add missing space between notable trait tooltip and where clause)
- #102119 (Fix a typo “pararmeter” in error message)
- #102131 (Added which number is computed in compute_float.)
Failed merges:
r? `@ghost`
`@rustbot` modify labels: rollup
Added which number is computed in compute_float.
The original comment was very elaborate but ultimately did not mention at all what is being computed using parameters `w, q`, only referencing an external article for the algorithm.
rustc_transmute: fix big-endian discriminants
I noticed that some new tests were failing in Fedora on s390x only, which usually means there's a problem with big-endian, and sure enough there's a FIXME(``@jswrenn)`` for that in `rustc_transmute`. This patch implements the appropriate consideration for target endianness, rather than using native (host) endian.
Make cycle errors recoverable
In particular, this allows rustdoc to recover from cycle errors when normalizing associated types for documentation.
In the past, ```@jackh726``` has said we need to be careful about overflow errors: https://github.com/rust-lang/rust/pull/91430#issuecomment-983997013
> Off the top of my head, we definitely should be careful about treating overflow errors the same as
"not implemented for some reason" errors. Otherwise, you could end up with behavior that is
different depending on recursion depth. But, that might be context-dependent.
But cycle errors should be safe to unconditionally report; they don't depend on the recursion depth, they will always be an error whenever they're encountered.
Helps with https://github.com/rust-lang/rust/issues/81091.
r? ```@lcnr``` cc ```@matthewjasper```
Remove use of `io::ErrorKind::Other` in std
The documentation states that this `ErrorKind` is not used by the standard library. Instead, `io::ErrorKind::Uncategorized` should be used.
The two instances are in the unstable API [linux_pidfd](https://github.com/rust-lang/rust/issues/82971).
Update rustc's information on Android's sanitizers
This patch updates sanitizer support definitions for Android inside the compiler. It also adjusts the logic to make sure no pre-built sanitizer runtime libraries are emitted as these are instead provided dynamically on Android targets.
Normalize opaques w/ bound vars
First, we reenable normalization of opaque types with escaping late bound regions to fix rust-lang/miri#2433. This essentially reverts #89285.
Second, we mitigate the perf regression found in #88862 by simplifying the way that we relate (sub and eq) GeneratorWitness types.
This relies on the fact that we construct these GeneratorWitness types somewhat particularly (with all free regions found in the witness types replaced with late bound regions) -- but those bound regions really should be treated as existential regions, not universal ones. Those two facts leads me to believe that we do not need to use the full `higher_ranked_sub` machinery to relate two generator witnesses. I'm pretty confident that this is correct, but I'm glad to discuss this further.
use partition_point instead of binary_search when looking up source lines
In local benchmarks this results in 0.4% fewer cycles in a critical sequential section when compiling libcore.
This rule was added to help position the marker line in
110e7270ab, which was a `position: absolute`
pseudo-element that relied on its parent to put it in the right spot.
The arrow was removed in 73d0f7c7b6, so the
`relative` position is no longer necessary.
