Later in this stack, as the nonzero_integers macro is going to be
responsible for producing a larger fraction of the API for the NonZero
integer types, it will need to receive a number of additional arguments
beyond the ones currently seen here.
Additional arguments, especially named arguments across multiple lines,
will turn out clearer if everything in one macro call is for the same
NonZero type.
This commit adopts a similar arrangement to what we do for generating
the API of the integer primitives (`impl u8` etc), which also generate a
single type's API per top-level macro call, rather than generating all
12 impl blocks for the 12 types from one macro call.
This way all the other macros defined in this module, such as
nonzero_leading_trailing_zeros, are available to call within the expansion of
nonzero_integers.
(Macros defined by macro_rules cannot be called from the same module above the
location of the macro_rules.)
In this commit the ability to call things like nonzero_leading_trailing_zeros is
not immediately used, but later commits in this stack will be consolidating the
entire API of NonZeroT to be generated through nonzero_integers, and will need
to make use of some of the other macros to do that.
[meta] Remove Zulip rustdoc nomination alert
There no longer exists the label <kbd>I-nominated</kbd>, it's no longer possible to trigger the Zulip nomination alert. Nowadays, there are separate <kbd>I-{team}-nominated</kbd> labels one for each team that make use of such a nomination system.
Since t-rustdoc has never really used this nomination system, I figured I should remove it outright. However, instead of that, I could create the label <kbd>I-rustdoc-nominated</kbd> and adjust the triagebot entry. Whatever you prefer.
r? GuillaumeGomez or rustdoc
Don't ICE when noting GAT bounds in `report_no_match_method_error`
We can encounter `BindingObligation`s from GATs that we should handle in `report_no_match_method_error`. I assume we can encounter them from methods, though I didn't really feel like wasting my time creating a repro.
Fixes#119942
Make `InferCtxtExt::could_impl_trait` more precise, less ICEy
The implementation for `InferCtxtExt::could_impl_trait` was very wrong. Along with being pretty poorly named, way too specific to ADTs, it was also doing impl substitution wrong -- this caused an ICE (#119915).
This PR generalizes that code, gives it a clearer name, makes it stop using the new trait solver (lol), and fixes some fallout bad suggestions that are made worse with the code fix.
Fixes#119915
Improve UEFI target docs
* Add a section showing exactly how to build a driver instead of an application
* Add links to the crates mentioned in the doc
CC `@dvdhrm`
Move personality implementation out of PAL
The module already follows the new convention described in #117276. This PR also includes a small fix in the tidy pal check, that was just an oversight in #117285.
store the segment name when resolution fails
Fixes#112672
The `find_cfg_stripped` does indeed get executed within `smart_resolve_report_errors`. However, this error is not reported as it is subsequently overridden by `parent_err`. (See: https://github.com/rust-lang/rust/blob/master/compiler/rustc_resolve/src/late.rs#L3760)
This PR changes `last_segment` to `segment`, which stores the name of the failed resolution, and ensures that the result of `find_cfg_stripped` is also included in `parent_err`.
r? ```@Nilstrieb```
Suggest Upgrading Compiler for Gated Features
This PR addresses #117318
I have a few questions:
1. Do we want to specify the current version and release date of the compiler? I have added this in via environment variables, which I found in the code for the rustc cli where it handles the `--version` flag
a. How can I handle the changing message in the tests?
3. Do we want to only show this message when the compiler is old?
a. How can we determine when the compiler is old?
I'll wait until we figure out the message to bless the tests
