8443: Rewrite `#[derive]` removal code to be based on AST r=jonas-schievink a=jonas-schievink
We now remove any `#[derive]` before and including the one we want to expand, in the `macro_arg` query.
The same infra will be needed by attribute macros (except we only remove the attribute we're expanding, not any preceding ones).
Part of https://github.com/rust-analyzer/rust-analyzer/issues/8434 (doesn't implement the cfg-expansion yet, because that's more difficult)
8446: Undo path resolution hack for extern prelude r=jonas-schievink a=jonas-schievink
Reverts the change made in https://github.com/rust-analyzer/rust-analyzer/pull/7959
We don't populate the extern prelude for block DefMaps anymore,
so this is unnecessary
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Rationale: only a minority of variants used almost half the size.
By keeping large members (especially in Option) behind a box
the memory cost is only payed when the large variants are needed.
This reduces the size Vec<Expr> needs to allocate.
8352: Remove dead legacy macro expansion code r=lnicola a=brandondong
I was investigating some unrelated macro issue when I noticed this dead code. This legacy macro expansion logic was changed in https://github.com/rust-analyzer/rust-analyzer/pull/8128.
Co-authored-by: Brandon <brandondong604@hotmail.com>
8245: Properly resolve intra doc links in hover and goto_definition r=matklad a=Veykril
Unfortunately involves a bit of weird workarounds due to pulldown_cmark's incorrect lifetimes on `BrokenLinkCallback`... I should probably open an issue there asking for the fixes to be pushed to a release since they already exist in the repo for quite some time it seems.
Fixes#8258, Fixes#8238
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
Bitflags is generally a good dependency -- it's lightweight, well
maintained and embraced by the ecosystem.
I wonder, however, do we really need it? Doesn't feel like it adds much
to be honest.
8322: Access a body's block def maps via a method r=jonas-schievink a=jonas-schievink
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
Only one upgradeable read lock can be handed out at the same time, and
we never acquire a non-upgradeable read lock, so this has no benefit
over just using a write lock in the first place.
