Skip to content

Streamline define_dep_nodes.#152525

Open
nnethercote wants to merge 1 commit intorust-lang:mainfrom
nnethercote:dep_kinds-stuff
Open

Streamline define_dep_nodes.#152525
nnethercote wants to merge 1 commit intorust-lang:mainfrom
nnethercote:dep_kinds-stuff

Conversation

@nnethercote
Copy link
Contributor

Changes that make this macro easier to read.

  • DepKindDefs is an enum that is used purely to generate a list of ascending numbers at compile time, to implement the functions within dep_kinds. This commit replaces it with a ${index()} macro metavar. (The comment about u16 data representation doesn't seem relevant any more.)

  • DEP_KIND_VARIANTS just counts the number of dep kind variants. It's implemented via len() and a const loop to ensure DepKindDefs truly implements a list of ascending numbers. This commit replaces it with a ${count(..)} macro metavar. This commit also renames it to make clearer it's a count of varants, not an actual list/array/vec of variants.

  • This commit uses stringify! more for variant-names-as-strings, instead of going indirectly via label_strs.

r? @saethlin

Changes that make this macro easier to read.

- `DepKindDefs` is an enum that is used purely to generate a list of
  ascending numbers at compile time, to implement the functions within
  `dep_kinds`. This commit replaces it with a `${index()}` macro
  metavar. (The comment about u16 data representation doesn't seem
  relevant any more.)

- `DEP_KIND_VARIANTS` just counts the number of dep kind variants. It's
  implemented via `len()` and a const loop to ensure `DepKindDefs` truly
  implements a list of ascending numbers. This commit replaces it with a
  `${count(..)}` macro metavar. This commit also renames it to make
  clearer it's a count of varants, not an actual list/array/vec of
  variants.

- This commit uses `stringify!` more for variant-names-as-strings,
  instead of going indirectly via `label_strs`.
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels Feb 12, 2026
pub(super) fn dep_kind_from_label_string(label: &str) -> Result<DepKind, ()> {
match label {
$( self::label_strs::$variant => Ok(self::dep_kinds::$variant), )*
$( stringify!($variant) => Ok(self::dep_kinds::$variant), )*
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This actually reverts a recent change from @Zalathar (17c5b7a).
I guess there are different opinions on what is more streamlined (I'm not sure personally).

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

At the time I was thinking that it would be good to reduce the amount of stringify!($name), but I'm not actually very confident about that being the right direction.

So with hindsight, I don't really object to changing it back.

@Zalathar
Copy link
Member

For some historical context, the split between DepKind and enum DepKindDefs was introduced by #115920, as part of the ambition of detaching queries from rustc_middle, which didn't really pan out in the intervening years.

I don't know if that has actionable consequences for this PR, but it seems worth bearing in mind as we continue to dismantle rustc_query_system.

Comment on lines -46 to -56
pub(crate) const DEP_KIND_VARIANTS: u16 = {
let deps = &[$(dep_kinds::$variant,)*];
let mut i = 0;
while i < deps.len() {
if i != deps[i].as_usize() {
panic!();
}
i += 1;
}
deps.len() as u16
};
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we have any other check that the numeric values continue to be dense and ascending from 0?

That's currently still true in the new implementation, but I don't know if there's anything ensuring that it remains true.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants