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.
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.
Notify when an `I-prioritize` issue is closed or reopened
Companion PR to rust-lang/triagebot#1078, blocked on that PR.
r? ``@spastorino`` cc ``@rust-lang/wg-prioritization``
ast_lowering: Introduce `lower_span` for catching all spans entering HIR
This PR cherry-picks the `fn lower_span` change from https://github.com/rust-lang/rust/pull/84373.
I also introduced `fn lower_ident` for lowering spans in identifiers, and audited places where HIR structures with spans or identifiers are constructed and added a few missing `lower_span`s/`lower_ident`s.
Having a hook for spans entering HIR can be useful for things other than https://github.com/rust-lang/rust/pull/84373, e.g. https://github.com/rust-lang/rust/issues/35148.
I also want to check whether this change causes perf regressions due to some accidental inlining issues.
r? `@cjgillot`
Update the stdarch submodule
This notably brings in a number of codegen updates to ensure that wasm
simd intrinsics generate the expected instruction with LLVM 13
Make `-Z gcc-ld=lld` work for Apple targets
`-Z gcc-ld=lld` was introduced in #85961. It does not work on Macos because lld needs be either named `ld64` or passed `-flavor darwin` as the first two arguments in order to select the Mach-O flavor. Rust invokes cc (=clang) on Macos for linking which calls `ld` as linker binary and not `ld64`, so just creating an `ld64` binary and modifying the search path with `-B` does not work.
In order to solve this patch does:
* Set the `lld_flavor` for all Apple-derived targets to `LldFlavor::Ld64`. As far as I can see this actually works towards fixing `-Xlinker=rust-lld` as all those targets use the Mach-O object format.
* Copy/hardlink rust-lld to the gcc-ld subdirectory as ld64 next to ld.
* If `-Z gcc-ld=lld` is used and the target lld flavor is Ld64 add `-fuse-ld=/path/to/ld64` to the linker invocation.
Fixes#86945.
Add Saturating type (based on Wrapping type)
Tracking #87920
### Unresolved Questions
<!--
Include any open questions that need to be answered before the feature can be
stabilised.
-->
- [x] ~`impl Div for Saturating<T>` falls back on inner integer division - which seems alright?~
- [x] add `saturating_div`? (to respect division by `-1`)
- [x] There is no `::saturating_shl` and `::saturating_shr`. (How to) implement `Shl`, `ShlAssign`, `Shr` and `ShrAssign`?
- [naively](3f7d2ce28f)
- [x] ~`saturating_neg` is only implemented on [signed integer types](https://doc.rust-lang.org/std/?search=saturating_n)~
- [x] Is the implementation copied over from the `Wrapping`-type correct for `Saturating`?
- [x] `Saturating::rotate_left`
- [x] `Saturating::rotate_right`
- [x] `Not`
- [x] `BitXorOr` and `BitXorOrAssign`
- [x] `BitOr` and `BitOrAssign`
- [x] `BitAnd` and `BitAndAssign`
- [x] `Saturating::swap_bytes`
- [x] `Saturating::reverse_bits`
Macros 2.0-ify rustc_arena
For the purpose of battle-testing macros 2.0 I'm looking to dogfood it in rustc, one crate at a time.
(Note that there are only 12 changed lines if you ignore whitespace.)
build llvm libunwind.a in rustbuild
This PR move the building of llvm-libunwind from build script of libunwind to rustbuild, so user don't need a C compiler and recompile this C/C++ library when using build-std, and user can use codegen flags `link-self-contained` and cargo flag `build-std-features` to control the behavior of libunwind linking.
Add missing const edge case
We don't "process" const so we need to check for additional cases when the PatKind is a Path. We need to make sure that if there is only one variant that there is no field. If there is one or more field, we will want to borrow the match scrutinee
Closes https://github.com/rust-lang/rust/issues/88331
r? `@nikomatsakis`
Treat macros as HIR items
Macros have historically been treated differently from other items at the HIR level. This PR makes them just like normal items. There are a few special cases left over, which I've attempted to lay out below. By normalizing the treatment of macro items, this PR simplifies a fair bit of code and fixes some bugs at the same time. For more information, see #87406.
r? `@cjgillot`
## Backwards incompatibility
This is backwards incompatible in one small way. Due to a mistake, it was previously possible to apply stability attributes to an exported macro, even without enabling the `staged_api` feature. This never should have worked. After this PR, it will error, as it should. We could make it a warning instead, but that would require a special case for a feature that shouldn't ever have worked and is likely used by no or very few crates, so I'm not thrilled about the idea.
## Notes for reviewers
### Commit seperation
I'd recommend reviewing this PR commit by commit. The commit chunking wasn't perfect, but it's better than looking at the combined diff, which is quite overwhelming. The compiler and standard library build after each commit, although tests do not necessarily pass and tools do not necessarily build till the end of the series.
### Special cases
There are a few special cases that remain after this change. Here are the notable ones I remember:
1. Visibility works a bit differently for `macro_rules!` macros than other items, since they aren't generally marked with `pub` but instead with `#[macro_export]`.
2. Since `#[macro_export]` macros always have paths at the top level of the crate, some additional handling needs to be done on the reexport to top level.
### Performance impact
I don't know for sure, but theses changes may slightly hurt performance. They create more work for the compiler in a few places. For instance, some operations that were previously run only for exported macros are now run for all macros. A perf run is probably advisable. For all I know we'll see performance improvements instead. :)
## Issues resolved
This resolves#87406 (the tracking issue for this change). It also fixes several bugs:
Fixes#59306.
Fixes#73754.
Fixes#87257.
S390x inline asm
This adds register definitions and constraint codes for the s390x general and floating point registers necessary for fixing #85931; as well as a few tests.
Further testing is needed, but I am a little unsure of what specific tests should be added to `src/test/assembly/asm/s390x.rs` to address this.
