Cleanup: rename node_id_to_type(_opt)
Renames `node_id_to_type(_opt)` to `hir_id_to_type(_opt)`; this makes it clear we are dealing with HIR nodes and their IDs here.
In addition, a drive-by commit removing `ty::item_path::hir_path_str` (as requested by @eddyb).
Cosmetic improvements to doc comments
This has been factored out from https://github.com/rust-lang/rust/pull/58036 to only include changes to documentation comments (throughout the rustc codebase).
r? @steveklabnik
Once you're happy with this, maybe we could get it through with r=1, so it doesn't constantly get invalidated? (I'm not sure this will be an issue, but just in case...) Anyway, thanks for your advice so far!
Currently, the target of a use statement will be updated with
the visibility of the use statement itself (if the use statement was
visible).
This commit ensures that if the path to the target item is via another
use statement then that intermediate use statement will also have the
visibility updated like the target. This silences incorrect
`unreachable_pub` lints with inactionable suggestions.
Implement public/private dependency feature
Implements https://github.com/rust-lang/rust/issues/44663
The core implementation is done - however, there are a few issues that still need to be resolved:
- [x] The `EXTERNAL_PRIVATE_DEPENDENCY` lint currently does notthing when the `public_private_dependencies` is not enabled. Should mentioning the lint (in an `allow` or `deny` attribute) be an error if the feature is not enabled? (Resolved- the feature was removed)
- [x] Crates with the name `core` and `std` are always marked public, without the need to explcitily specify them on the command line. Is this what we want to do? Do we want to allow`no_std`/`no_core` crates to explicitly control this in some way? (Resolved - private crates are now explicitly specified)
- [x] Should I add additional UI tests? (Resolved - added more tests)
- [x] Does it make sense to be able to allow/deny the `EXTERNAL_PRIVATE_DEPENDENCY` on an individual item? (Resolved - this is implemented)
fix `is_non_exhaustive` confusion between structs and enums
Structs and enums can both be non-exhaustive, with a very different
meaning. This PR splits `is_non_exhaustive` to 2 separate functions - 1
for structs, and another for enums, and fixes the places that got the
usage confused.
Fixes#53549.
r? @eddyb
