feature: add #[salsa::interned_sans_lifetime] macro

[davidbarsky]

(This consolidates #618, #620, and #623 into a single PR, logical PR.)

Here's what this solves:

1. the 'db lifetime on interned structs makes migrating some rust-analyzer's existing interned values really challenging.
2. rust-analyzer wants to fiddle with the underlying ID.
3. We'd like to be able to fetch the associated, interned data without having the wrapped, interned struct on hand.

We'll probably port rust-analyzer over the new, idiomatic API instead, but this makes the migration a lot easier!

[netlify]

✅ Deploy Preview for salsa-rs canceled.

Name	Link
🔨 Latest commit	2cc5193
🔍 Latest deploy log	https://app.netlify.com/sites/salsa-rs/deploys/677db7607c93120008eda93f

[codspeed-hq]

CodSpeed Performance Report

Merging #632 will not alter performance

_{Comparing davidbarsky:davidbarsky/add-interned-sans-lifetime-macro (2cc5193) with master (7ca9695)}

Summary

✅ 9 untouched benchmarks

[nikomatsakis]

@davidbarsky ....

---- components/salsa-macros/src/lib.rs - interned_sans_lifetime (line 91) stdout ----
error[E0433]: failed to resolve: use of undeclared crate or module `salsa`
  --> components/salsa-macros/src/lib.rs:107:3
   |
18 | #[salsa::interned_sans_lifetime(id = CustomSalsaIdWrapper)]
   |   ^^^^^ use of undeclared crate or module `salsa`

[MichaReiser]

We discussed that we want to discourage this pattern but it would also be nice if we can avoid duplicating the interned macro. Would it be possible to gate the functionality behind a feature? E.g. that the interned macro only supports a no_lifetime argument if salsa_macros is used with the compat feature.

[Veykril]

Given the goal is for this to only ease the transition for r-a it should be fine (and honestly preferred in my eyes) to gate this behind a feature until r-a no longer needs it (at which point we can remove it again).

[davidbarsky]

To expand as to why this is a separate macro instead of something like #[salsa::interned(no_lifetime)], there are two reasons:

1. I wrote this for expediency's sake to confirm whether this is something that I even want/need in rust-analyzer. Copying is pretty easy, after all!
2. I didn't know how to make $db_lt optional in a macro_rules-based macro: namely, it's not clear to me how I can do control flow as I'd do in a proc macro, but this might be my inexperience with macro_rules :).
   1. If it's not possible to do control flow in a macro_rules-based macro; a default lifetime parameter a la https://internals.rust-lang.org/t/default-lifetime-parameters/12073 would've been great, but, unfortunately, that doesn't exist today.

[MichaReiser]

It's hard to tell for me what the difference is between the two macros but would it be possible to change $db_lt to either be <'db> (so that it includes the <..> or an empty string ifno_lifetime` is used.

Or you might be able to do something similar to clone and no_clone

https://github.com/MichaReiser/salsa/blob/e68679b3a9c2b5cfd8eab92de89edf4073b03601/components/salsa-macro-rules/src/maybe_clone.rs#L5-L21

[davidbarsky]

It's hard to tell for me what the difference is between the two macros

I do too, but difftastic helped here. I don't think it's a particularly useful paste, but if you have it handy, difft components/salsa-macro-rules/src/setup_interned_struct.rs components/salsa-macro-rules/src/setup_interned_struct_sans_lifetime.rs will show the difference. The primary differences are:

1. The addition of a StructData parameter to the macro. I didn't want pull in paste, so I just made the ident in the proc macro.
2. The addition of the $Id parameter, to allow the ID overriding behavior we need in rust-analyzer.
3. Moving salsa::plumbing::interned::Configuration out of the const _: () = {...} block in order to get the data through the underlying ID alone.
4. The removal of lifetimes and a few select additions of 'static, as needed.

I honestly recommend cloning this PR and diffing via difftastic.

would it be possible to change $db_lt to either be <'db> (so that it includes the <..>) or an empty string if no_lifetime is used?

Not that I'm aware of, at least with macro_rules!-based macros. I don't think we can invoke maybe_*-style macros in the type position. From a "how can we unify these macros", I think it'd require moving things away from salsa-macro-rules into a (mostly) pure quote!-based approach.

[davidbarsky]

I fixed the rustdoc failures, but I can't reproduce the test failure w.r.t to cancellation on my Mac. That's a bit concerning, but I think I'll try and debug this tomorrow.

[Veykril]

I question the need for the id = part actually, I'll raise the why in the rust-analyzer zulip but just so people know. I don't think r-a needs that part. That is only the lifetime part is required.

Turns out yes we can drop that part https://rust-lang.zulipchat.com/#narrow/channel/185405-t-compiler.2Frust-analyzer/topic/Porting.20to.20Salsa.203.2E0/near/490407386

[davidbarsky]

I fixed the rustdoc failures, but I can't reproduce the test failure w.r.t to cancellation on my Mac. That's a bit concerning, but I think I'll try and debug this tomorrow.

Lukas found and fixed the issue in #637.

[nikomatsakis]

I'm sure we'll discuss today -- but I think this is fine as a transitionary step. I can even see a potential role for this more generally (see this comment) but we could land that separately. My major qualm here is that there seems to be quite a bit of code duplication. I know this is intended to be temporary so maybe that's fine, I do wonder though how temporary it will turn out to be.

[davidbarsky]

Closing in favor of #661, which has substantially less duplication and removes support for overriding IDs.