Skip to content

Add 'db lifetime to BuiltinDeriveMacroId - #23060

Open
ada4a wants to merge 4 commits into
rust-lang:masterfrom
ada4a:lt-for-BuiltinDeriveMacroId
Open

Add 'db lifetime to BuiltinDeriveMacroId#23060
ada4a wants to merge 4 commits into
rust-lang:masterfrom
ada4a:lt-for-BuiltinDeriveMacroId

Conversation

@ada4a

@ada4a ada4a commented Aug 6, 2026

Copy link
Copy Markdown
Contributor

Part of #22868

@rustbot rustbot added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Aug 6, 2026
@rustbot

This comment has been minimized.

@ada4a
ada4a force-pushed the lt-for-BuiltinDeriveMacroId branch from 3299abc to 43c5b6d Compare August 6, 2026 13:08
@rustbot

This comment has been minimized.

@ada4a
ada4a force-pushed the lt-for-BuiltinDeriveMacroId branch 4 times, most recently from d3f8893 to d5387cb Compare August 6, 2026 13:19

@ChayimFriedman2 ChayimFriedman2 left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I'm a bit hesitant to merge this while @dfireBird has its lifetimes PR in flight; this PR is much easier to review but the work there is definitely higher...

View changes since this review

Comment thread crates/hir-def/src/attrs/docs.rs Outdated
) {
// Lazily initialised when we first encounter a `#[doc = macro!()]`.
let mut expander: Option<DocMacroExpander<'db>> = None;
let mut expander = LazyCell::new(|| {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Why this change? (LazyCell has an additional branch).

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Mostly code clarity I'd say? LazyCell makes it very clear what's happening: a value that is initialized lazily.

LazyCell has an additional branch

You mean to check whether the value has been initialized or not? But I think Option::get_or_insert_with does a similar check for None, no?

Anyway I don't feel too strongly about this, happy to revert.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

LazyCell needs to check for reentrance.

I wouldn't oppose if this was written this way to begin with, but I do oppose changing it in an unrelated PR.

Comment thread crates/hir-def/src/nameres/path_resolution.rs
Comment thread crates/hir-def/src/dyn_map.rs Outdated
}

#[cfg(test)]
mod tests {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Why this test? Is it for the DynMap? Most of it is type gymnastics, I don't think it needs tests.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

It was a leftover from Lukas' code snippet – I'll remove it if you say it's unnecessary

Comment thread crates/hir-def/src/lib.rs Outdated
}

#[salsa::interned(debug, unsafe(no_lifetime), revisions = usize::MAX)]
#[salsa::interned(debug)]

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I wouldn't remove revisions = usize::MAX yet. We need to take a conscious decision to enable interneds GC and in what frequency.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Note that it was only recently added in during salsa upgrade (4d59eee#diff-8a8808fa1cbb71d05f842b69e4bda92728af59464406b4aa58df635cea4c2571L357-R357), because salsa started requiring it when no_lifetime is present. Still, I'll re-add it for now.

lang_items: &'db LangItems,
resolver: &'a Resolver<'db>,
store: &'db ExpressionStore,
store: &'a ExpressionStore,

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Why this change? It should remain 'db.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Basically, because of this:

error[E0597]: `store` does not live long enough
   --> crates/hir/src/source_analyzer.rs:402:17
    |
109 |   impl<'db> SourceAnalyzer<'db> {
    |        --- lifetime `'db` defined here
...
383 |           let (store, params, _) = lower_generic_params(
    |                ----- binding `store` declared here
...
399 |               match where_predicate_must_hold(
    |  ___________________-
400 | |                 db,
401 | |                 &self.resolver,
402 | |                 &store,
    | |                 ^^^^^^ borrowed value does not live long enough
...   |
406 | |                 predicate,
407 | |             ) {
    | |_____________- argument requires that `store` is borrowed for `'db`
...
421 |       }
    |       - `store` dropped here while still borrowed

here, lower_generic_params creates store: ExpressionStore, and when we try to pass a reference to that to where_predicate_must_hold, the lifetime of that reference doesn't live enough (for 'db), because store is only live inside the function body.

I think it's fair to say that in general, if a struct/enum has a field of type &T (like TyLoweringContext.store: &ExpressionStore), then the lifetime of that reference shouldn't be 'db, because that makes things invariant over 'db.

@ada4a

ada4a commented Aug 6, 2026

Copy link
Copy Markdown
Contributor Author

Happy to wait for @dfireBird's PR to land first – I honestly doubted I would be able to drive this to completion, but since I now have, fixing it up as needed (by reading) sounds doable

@rustbot

This comment has been minimized.

@ada4a
ada4a force-pushed the lt-for-BuiltinDeriveMacroId branch from d5387cb to c291d7b Compare August 10, 2026 18:42
ada4a and others added 4 commits August 10, 2026 21:30
- use `from_id!` for `EnumVariant{,Id}`
- use `?` for consistency with the other methods
- rm needlessly complicated `Ordering` clause
- use chained if-lets to reduce nesting
- rm manual lifetime expansion (`parent_arc` seems to have been an Arc
  in the past)
- use `.into()` to turn things into `Definition`s
A lot of these were necessary to allow the next commit to compile, but a
few are miscellaneous.
@ada4a
ada4a force-pushed the lt-for-BuiltinDeriveMacroId branch from c291d7b to 4539b3a Compare August 10, 2026 19:41
@rustbot

rustbot commented Aug 10, 2026

Copy link
Copy Markdown
Collaborator

This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

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.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants