I'm interested in contributing to https://github.com/rust-analyzer/rust-analyzer/issues/8971 - is there already ongoing work on it?
I have done some work on the prerequisites
The next steps here are:
Re: the attribute API – this can possibly be skipped for an MVP, but is probably already causing issues with how we strip
#[derive] attributes today.
Basically the issue is that we try to uniquely identify attributes without accounting for
cfg_attr, which can expand to any number of attributes. This then leads to us stripping the entire
cfg_attr instead of just one of the expanded attributes. It has also causes hangs, where I assumed that attribute IDs are unique (I've fixed or papered over those now).
One thing that would also help rust-analyzer would be if we didn't have to duplicate this file but could somehow reuse it: https://github.com/rust-analyzer/rust-analyzer/blob/master/crates/hir_def/src/builtin_attr.rs
EXTRA_ATTRIBUTES const is new, that would go away if we add proper support for the builtin attribute macros - it's also very incomplete apparently :laughing: )
@Jonas Schievink [he/him] Are you able to depend on
not directly, since we target stable
rustc_feature also uses rustc's list of known symbols, which we don't have
rust-analyzer depend on any rustc internal crates?
on the lexer, yeah
outside of that, no, but we do use chalk, and have vendored the proc_macro bridge
(I'd also like to stop vendoring the proc_macro code since it tends to break often, but this requires some more complicated changes I think)
To expand on "depend on rustc", we totally can and want to depend on
rustc crates, as long as they are build with stable. So, extracting the attribute data table into a separate, "builds on stable" crate would help us, yeah. To be clear, we don't need the APIs to be stable, we are 100% comfortable following whatever changes happen in rustc, as long as "builds on stable" is observed.
Also, @Aaron Hill excited to see experienced rustc hackers taking a look at rust-analyzer. If you need anything to mover forward, feel free to ping us!
rustc_features uses the
once_cell feature gate and depends on
rustc_data_structures dependency is easy to remove as it only uses
rustc_span dependency is used for
sym, making it much harder to remove.
rustc_span uses several feature gates.
Yeah, there's no analogue to
spans in rust-analyzer, so any sharing needs to be done in such a way that the callee supplies the span info.
sooo, it turns out we already have most things in place to let this "work", for some values of "work"
everything else breaks tho
ship it? :see_no_evil:
(what's 'everything else'?)
all the salsa macros apparently expand to thin air
I think we're just missing the attribute arguments here
but I did expect at least some sort of diagnostic
also I think the
TokenMap isn't working, and maybe child_by_source also doesn't
so there's still quite a bit of work to do
pushed the code here for now: https://github.com/jonas-schievink/rust-analyzer/tree/expand-attr-macros
@matklad Can you elaborate on the motivation behind the compiles-on-stable requirement? Given the extensive use of nightly features in compiler crates, it seems like that requirement causes (or will cause) a large amount of duplication between rustc and rust-analyzer. I can see the value in having independent implementations of different parts of the compiler, but it sounds like you would potentially depend on many more
rustc crates if you were able to.
rust-analyzer were to be made a subtreee (I don't know if there's been any discussion of this), then in my (perhaps naive) view, it could function similar to clippy
Personally I would be fine with targeting nightly instead, if we use a
rust-toolchain file we should get roughly the same contributor experience
It requires nightly, uses many compiler crates, but AFAIK that doesn't cause problems
of course, clippy is also distributed via rustup
So there are two parts here:
1) just using unstable features
2) relying on unstable features for bootstraping purposes
Both have a disadvantage that they make iterating on
rust-analyzer itself significantly harder, especially for new contributors. Fast, reliable build & test process is something we optimize for a lot, to make code base more accessible, and to be able to ship more things faster ourselves.
Long term, when we start actually sharing significant parts of code with rustc, I can see us forgoing 1). I'd fight tooth and nail for 2). It's not that I can't be defeated on that one, but I'll fight :-)
Before we reach the situation where a lot of code is shared, I think it makes sense to at least try to stick with stable.
chalk is a good example to learn from here.
I guess, ther's also
3) not using
That I think is hardest requirenment, as that goes directly the idea of proper, re-usable libraries.
Do we have any features in the
hir crates that can be controlled by the settings?
Because gating attribute macros behind one currently seems pretty annoying to do
I don't think we do
the setting would just be another input query, I guess?
hmm, yeah, that's pretty simple actually
we just can't forget to set it (does salsa have default values for input queries?)
hmm I don't know
okay, that was relatively straightforward