9069: minor: Don't force-disable incremental r=jonas-schievink a=jonas-schievink
1.52.1 turns incremental off regardless of this setting, so this is unnecessary. Removing this allow manually overriding Cargo to enable incremental.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9059: fix: Only complete derive proc macros in `#[derive]` r=jonas-schievink a=jonas-schievink
HIR now gives them `MacroKind::Derive` instead of `MacroKind::ProcMacro`
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9057: internal: Thread proc-macro types through the HIR r=jonas-schievink a=jonas-schievink
Should help with completion of derives. cc @Veykril
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9051: Fix incorrect setting descriptions r=lnicola a=sclu1034
Descriptions for diagnostic warning hint and info display were swapped.
Fixes#8485.
Co-authored-by: Lucas Schwiderski <lucas@lschwiderski.de>
9046: fix: make `include!` etc. work in expression position r=jonas-schievink a=jonas-schievink
This PR removes determination of fragment kinds from the eager macro implementations. The fragment kind is always determined by the syntax position in which a macro is invoked, not by the macro implementation, even for eager macros.
This makes `include!` work in expression position, and should have the same effect for all macros that may be used in different positions.
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
9027: feat: Attribute completion is context aware r=Veykril a=Veykril
This splits off the `lint` and `derive` completions into their own submodules of `attribute`.
The idea is to create a lazy global hashmap that maps `SyntaxKind` to attribute names(`&[&str]`) in which we index with the syntax kind of the "thing" we are attributing giving us the attributes back that are valid for this kind. Then we use this name to do a binary search on the attribute list to fetch and build the corresponding completion item.
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9040: Don't label derive macros with their banged_name r=Veykril a=Veykril
cc https://github.com/rust-analyzer/rust-analyzer/issues/7072#issuecomment-850396203
This doesn't fix it non builtin derives yet I think cause of a FIXME somewhere that doesn't categorize proc-macro derives as derives yet
bors r+
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
9029: minor: test that `ItemTree` makes `hir_def` queries syntax-independent r=jonas-schievink a=jonas-schievink
bors r+
Co-authored-by: Jonas Schievink <jonasschievink@gmail.com>
