6 Commits

Author SHA1 Message Date
Nicholas Nethercote ff1795fe49 Remove Clone impl for StableHashingContext.
`HashStable::hash_stable` takes a `&mut Hcx`. In contrast,
`ToStableHashKey::to_stable_hash_key` takes a `&Hcx`. But there are
some places where the latter calls the former, and due to the mismatch a
`clone` call is required to get a mutable `StableHashingContext`.

This commit changes `to_stable_hash_key` to instead take a `&mut Hcx`.
This eliminates the mismatch, the need for the clones, and the need for
the `Clone` impls.
2026-04-03 15:34:33 +11:00
Nicholas Nethercote 1a9a284ad2 Simplify HashStableContext.
`derive(HashStable_Generic)` generates impls like this:
```
impl<__CTX> HashStable<__CTX> for ExpnKind
where
    __CTX: crate::HashStableContext
{
    fn hash_stable(&self, hcx : &mut __CTX, __hasher: &mut StableHasher) {
        ...
    }
}
```
This is used for crates that are upstream of `rustc_middle`.

The `crate::HashStableContext` bound means every crate that uses
`derive(HashStable_Generic)` must provide (or import) a trait
`HashStableContext` which `rustc_middle` then impls. In `rustc_span`
this trait is sensible, with three methods. In other crates, this trait
is empty, and there is the following trait hierarchy:
```
rustc_session::HashStableContext
  |              |
  |   rustc_hir::HashStableContext
  |         /                   \
rustc_ast::HashStableContext   rustc_abi::HashStableContext
  |
rustc_span::HashStableContext
```
All very strange and unnecessary. This commit changes
`derive(HashStable_Generic)` to use `rustc_span::HashStableContext`
instead of `crate::HashStableContext`. This eliminates the need for all
the empty `HashStableContext` traits and impls. Much better.
2026-04-01 17:52:43 +11:00
Nicholas Nethercote ccc3c01162 Use Hcx/hcx consistently for StableHashingContext.
The `HashStable` and `ToStableHashKey` traits both have a type parameter
that is sometimes called `CTX` and sometimes called `HCX`. (In practice
this type parameter is always instantiated as `StableHashingContext`.)
Similarly, variables with these types are sometimes called `ctx` and
sometimes called `hcx`. This inconsistency has bugged me for some time.

The `HCX`/`hcx` form is more informative (the `H`/`h` indicates what
type of context it is) and it matches other cases like `tcx`, `dcx`,
`icx`.

Also, RFC 430 says that type parameters should have names that are
"concise UpperCamelCase, usually single uppercase letter: T". In this
case `H` feels insufficient, and `Hcx` feels better.

Therefore, this commit changes the code to use `Hcx`/`hcx` everywhere.
2026-03-31 20:16:57 +11:00
Oli Scherer ff7e604154 Stop using rustc_layout_scalar_valid_range_* in rustc 2026-03-07 15:36:56 +00:00
Josh Triplett 2ea7e7da00 rustc_hir_id: Add a comment explaining why the crate exists 2025-08-20 15:04:00 -07:00
Josh Triplett f3c8b7ad40 Split rustc_hir_id out of rustc_hir
Some crates depend on `rustc_hir` but only want `HirId` and similar id
types. `rustc_hir` is a heavy dependency, since it pulls in
`rustc_target`. Split these types out into their own crate
`rustc_hir_id`.

This allows `rustc_errors` to drop its direct dependency on `rustc_hir`.

(`rustc_errors` still depends on `rustc_hir` indirectly through
`rustc_lint_defs`; a subsequent commit will fix that.)
2025-08-20 15:01:13 -07:00