Do not mark unit variants as used when in path pattern
Record that we are processing a pattern so that code responsible for
handling path resolution can correctly decide whether to mark it as
used or not.
Closes#76788.
Separate out a `hir::Impl` struct
This makes it possible to pass the `Impl` directly to functions, instead
of having to pass each of the many fields one at a time. It also
simplifies matches in many cases.
See `rustc_save_analysis::dump_visitor::process_impl` or `rustdoc::clean::clean_impl` for a good example of how this makes `impl`s easier to work with.
r? `@petrochenkov` maybe?
This makes it possible to pass the `Impl` directly to functions, instead
of having to pass each of the many fields one at a time. It also
simplifies matches in many cases.
passes: prohibit invalid attrs on generic params
Fixes#78957.
This PR modifies the `check_attr` pass so that attribute placement on generic parameters is checked for validity.
r? `@lcnr`
Allow `since="TBD"` for rustc_deprecated
Closes#78381.
This PR only affects `#[rustc_deprecated]`, not `#[deprecated]`, so there is no effect on any stable language feature.
Likewise this PR only implements `since="TBD"`, it does not actually tag any library functions with it, so there is no effect on any stable API.
Overview of changes:
* `rustc_middle/stability.rs`:
* change `deprecation_in_effect` function to return `false` when `since="TBD"`
* tidy up the compiler output when a deprecated item has `since="TBD"`
* `rustc_passes/stability.rs`:
* allow `since="TBD"` to pass the sanity check for stable_version < deprecated_version
* refactor the "invalid stability version" and "invalid deprecation version" error into separate errors
* rustdoc: make `since="TBD"` message on a deprecated item's page match the command-line deprecation output
* tests:
* test rustdoc output
* test that the `deprecated_in_future` lint fires when `since="TBD"`
* test the new "invalid deprecation version" error message
Implement if-let match guards
Implements rust-lang/rfcs#2294 (tracking issue: #51114).
I probably should do a few more things before this can be merged:
- [x] Add tests (added basic tests, more advanced tests could be done in the future?)
- [x] Add lint for exhaustive if-let guard (comparable to normal if-let statements)
- [x] Fix clippy
However since this is a nightly feature maybe it's fine to land this and do those steps in follow-up PRs.
Thanks a lot `@matthewjasper` ❤️ for helping me with lowering to MIR! Would you be interested in reviewing this?
r? `@ghost` for now
Simplify visit_{foreign,trait}_item
Using an `if` seems like a better semantic fit and saves a few lines.
Noticed while looking at https://github.com/rust-lang/rust/pull/79752, but that's already merged.
r? `@lcnr,` cc `@cjgillot`
`@rustbot` modify labels +C-cleanup +T-compiler
Compress RWU from at least 32 bits to 4 bits
The liveness uses a mixed representation of RWUs based on the
observation that most of them have invalid reader and invalid
writer. The packed variant uses 32 bits and unpacked 96 bits.
Unpacked data contains reader live node and writer live node.
Since live nodes are used only to determine their validity,
RWUs can always be stored in a packed form with four bits for
each: reader bit, writer bit, used bit, and one extra padding
bit to simplify packing and unpacking operations.
The liveness uses a mixed representation of RWUs based on the
observation that most of them have invalid reader and invalid
writer. The packed variant uses 32 bits and unpacked 96 bits.
Unpacked data contains reader live node and writer live node.
Since live nodes are used only to determine their validity,
RWUs can always be stored in a packed form with four bits for
each: reader bit, writer bit, used bit, and one extra padding
bit to simplify packing and unpacking operations.
This commit modifies the `check_attr` pass so that attribute placement
on generic parameters is checked for validity.
Signed-off-by: David Wood <david@davidtw.co>
* Reject use of parameters inside naked function body.
* Reject use of patterns inside function parameters, to emphasize role
of parameters a signature declaration (mirroring existing behaviour
for function declarations) and avoid generating code introducing
specified bindings.