internal: Enforce utf8 paths
Cargo already requires this, and I highly doubt r-a works with non-utf8 paths generally either. This just makes dealing with paths a lot easier.
Add fuel to match checking
Exhaustiveness checking is NP-hard hence can take extremely long to check some specific matches. This PR makes ehxaustiveness bail after a set number of steps. I chose a bound that takes ~100ms on my machine, which should be more than enough for normal matches.
I'd like someone with less recent hardware to run the test to see if that limit is low enough for them. Also curious if the r-a team thinks this is a good ballpark or if we should go lower/higher. I don't have much data on how complex real-life matches get, but we can definitely go lower than `500 000` steps.
The second commit is a drive-by soundness fix which doesn't matter much today but will matter once `min_exhaustive_patterns` is stabilized.
Fixes https://github.com/rust-lang/rust-analyzer/issues/9528 cc `@matklad`
fix: Skip problematic cyclic dev-dependencies
Implements a workaround for https://github.com/rust-lang/rust-analyzer/issues/14167, notably it does not implement the ideas surfaced in the issue, but takes a simpler to implement approach (and one that is more consistent).
Effectively, all this does is discard dev-dependency edges that go from a workspace library target to another workspace library target. This means, using a dev-dependency to another workspace member inside unit tests will always fail to resolve for r-a now, (instead of being order dependent and causing problems elsewhere) while things will work out fine in integration tests, benches, examples etc. This effectively acknowledges package cycles to be okay, but crate graph cycles to be invalid:
Quoting https://github.com/rust-lang/rust-analyzer/issues/14167#issuecomment-1864145772
> Though, if you have “package cycle” in integration tests, you’d have “crate cycle” in unit test.
We disallow the latter here, while continuing to support the former
(What's missing is to supress diagnostics for such unit tests, though not doing so might be a good deterrent, making devs avoid the pattern altogether)
feat: Implement ATPIT
Resolves#16584
Note: This implementation only works for ATPIT, not for TAIT.
The main hinderence that blocks the later is the defining sites of TAIT can be inner blocks like in;
```rust
type X = impl Default;
mod foo {
fn bar() -> super::X {
()
}
}
```
So, to figure out we are defining it or not, we should recursively probe for nested modules and bodies.
For ATPIT, we can just look into current body because `error[E0401]: can't use 'Self' from outer item` prevent such nested structures;
```rust
trait Foo {
type Item;
fn foo() -> Self::Item;
}
struct Bar;
impl Foo for Bar {
type Item = impl Default;
fn foo() -> Self::Item {
fn bar() -> Self::Item {
^^^^^^^^^^
|
use of `Self` from outer item
refer to the type directly here instead
5
}
bar()
}
}
```
But this implementation does not checks for unification of same ATPIT between different bodies, monomorphization, nor layout for similar reason. (But these can be done with lazyness if we can utilize something like "mutation of interned value" with `db`. I coundn't find such thing but I would appreciate it if such thing exists and you could let me know 😅)
feat: Syntax highlighting improvements
Specifically
- Adds a new `constant` modifier, attached to keyword `const` (except for `*const ()` and `&raw const ()`), `const` items and `const` functions
- Adds (or rather reveals) `associated` modifier for associated items
- Fixes usage of the standard `static` modifier, now it acts like `associated` except being omitted for methods.
- Splits `SymbolKind::Function` into `Function` and `Method`. We already split other things like that (notable self param from params), so the split makes sense in general as a lot special cases around it anyways.
fix: handle attributes when typing curly bracket
fix#16848.
When inserting a `{`, if it is identified that the front part of `expr` is `attr`, we consider it as inserting `{}` around the entire `expr` (excluding the attr part).
Bump dependencies and use in-tree `rustc_pattern_analysis`
One last `pattern_analysis` API change. I don't have any more planned! So we can now use the in-tree version when available.
fix: Ignore some warnings if they originate from within macro expansions
These tend to be annoying noise as we can't handle `allow`s for them properly for the time being.
fix: incorrect handling of `use` and panic issue in `extract_module`.
fix#16826
This PR includes the following changes:
1. Simplify the implementation partially, removing many unnecessary loops and `clone()`.
2. When it is found that the top level of the selection contains a `use` statement, a copy of the `use` will be reinserted before extraction. (#16826)
3. Fixed an issue during `extract_module`, where if the top level of the selected part contains `A` and `use A::B`, it caused a duplication of `use A`.
fix: Fix wrong where clause rendering on hover
We were not accounting for proper newline indentation in some places making the hover look weird (or just straight up wrong for type aliases)
internal: Compress file text using LZ4
I haven't tested properly, but this roughly looks like:
```
1246 MB
59mb 4899 FileTextQuery
1008 MB
20mb 4899 CompressedFileTextQuery
555kb 1790 FileTextQuery
```
We might want to test on something more interesting, like `bevy`.
Stop eagerly resolving inlay hint text edits for VSCode
Send less json over the wire.
After https://github.com/microsoft/vscode/issues/193124 was fixed, this change is not needed anymore.
VSCode 1.86.0 now supports double click for unresolved hint data too.
Remove unncessary check for macro call
Since `macro_rules` is a contextual keyword, it is an `IDENT` token and thus `is_path_start` already identifies it correctly. You can tell the previous check is unnecessary because the relevant tests still pass.
internal: Improve readability of the parser code
The code is basically equivalent to the previous version, but it improves the readability by making it much more simpler and concise.
fix: Don't invalid body query results when generating desugared names
The hack remains until we get hygiene, but with this the generated names are stable across bodies
fix: Remove accidental dependency between `parse_macro_expansion` and `parse`
Turns out my idea from https://github.com/rust-lang/rust-analyzer/pull/15251 causes all builtin derive expansions to obviously rely on the main parse, meaning the entire `macro_arg` layer becomes kind of pointless. So this reverts that PR again.
internal: Implement parent-child relation for `SourceRoot`s
This commit adds the said relation by keeping a map of type `FxHashMap<SourceRootId,Option<SourceRootId>>` inside the `GlobalState`. Its primary use case is reading `rust-analyzer.toml`(#13529) files that can be placed in every local source root. As a config will be found by traversing this "tree" we need the parent information for every local source root. This commit omits defining this relation for library source roots entirely.
This commit adds the said relation by keeping a map of type `FxHashMap<SourceRootId,Option<SourceRootId>>`
inside the `GlobalState`. Its primary use case is reading the rust-analyzer.toml files that can be
placed under every local source root. As a config will be found by traversing this "tree" we need the parent information
for every local source root. This commit omits defining this relation for library source roots entirely.
