Update unstable docs for `asm!` macro
This adds documentation that SPIR-V is supported, expands on the restrictions for labels, and has some minor cleanups or clarifications.
r? `@joshtriplett`
Fix: don't document private macros by default
As part of #88019, I made it so private macros are documented in `--document-private-items` mode. Unfortunately, it appears that I also accidentally made them be documented when *not* in `--document-private-items` mode. This PR fixes that and adds a regression test.
r? `@jyn514` (I hope you don't mind that I keep sending PRs your way)
Fixes#88453.
`tcx.def_kind()` could theoretically invoke another query, which could
cause an infinite query loop. Accessing the HIR map directly makes that
less likely to happen.
I also changed it to use `as_local()` (`tcx.def_kind()` seems to
implicitly call `expect_local()`) and `opt_def_kind()` to reduce the
chance of panicking on valid code.
rustc_target: `TyAndLayout::field` should never error.
This refactor (making `TyAndLayout::field` return `TyAndLayout` without any `Result` around it) is based on a simple observation, regarding `TyAndLayout::field`:
If `cx.layout_of(ty)` succeeds (for some `cx` and `ty`), then `.field(cx, i)` on the resulting `TyAndLayout` should *always* succeed in computing `cx.layout_of(field_ty)` (where `field_ty` is the type of the `i`th field of `ty`).
The reason for this is that no matter which field is chosen, `cx.layout_of(field_ty)` *will have already been computed*, as part of computing `cx.layout_of(ty)`, as we cannot determine the layout of *any* type without considering the layouts of *all* of its fields.
And so it should be fine to turn any errors into ICEs, since they likely indicate a `cx` mismatch, or some other edge case that is due to a compiler bug (as opposed to ever being an user-facing error).
<hr/>
Each commit should probably be reviewed separately, though note that there's some `where` clauses (in `rustc_target::abi::call::*`) that change in most commits.
cc `@nagisa` `@oli-obk`
Handle match statements with non exhaustive variants in closures
This PR ensures that the behavior for match statements with non exhaustive variants is the same inside and outside closures.
If we have a non-exhaustive SingleVariant which is defined in a different crate, then we should handle the case the same way we would handle a MultiVariant: borrow the match discriminant.
Closes https://github.com/rust-lang/project-rfc-2229/issues/59
r? `@nikomatsakis`
Remove `Session.if_let_suggestions`
We can instead if either the LHS or RHS types contain
`TyKind::Error`. In addition to covering the case where
we would have previously updated `if_let_suggestions`, this might
also prevent redundant errors in other cases as well.
Fix formatting in release notes from 52a988344b
I neglected to add a line that allowed the `[cargo/9663]` short-hand to resolve to an actual link in the rendered markdown on github.
Remove vestigial rustfix tests.
The directory `src/test/rustfix` is not actually tested. It looks like a mistake was made when rustfix tests were originally introduced in #50084. In commit 6f2d023028 they were moved to `src/test/ui`, but the tests in the original directory weren't deleted.
Refactor Markdown length-limited summary implementation
This PR is a new approach to #79749.
This PR refactors the implementation of `markdown_summary_with_limit()`,
separating the logic of determining when the limit has been reached from
the actual rendering process.
The main advantage of the new approach is that it guarantees that all
HTML tags are closed, whereas the previous implementation could generate
tags that were never closed. It also ensures that no empty tags are
generated (e.g., `<em></em>`).
The new implementation consists of a general-purpose struct
`HtmlWithLimit` that manages the length-limiting logic and a function
`markdown_summary_with_limit()` that renders Markdown to HTML using the
struct.
r? `@GuillaumeGomez`
Suggestion for call on immutable binding of mutable type
When calling a method requiring a mutable self borrow on an inmutable
to a mutable borrow of the type, suggest making the binding mutable.
Fix#83241.
