feat: better completions for extern blcoks
This PR refactors `add_keywords` (making it much clearer!) and enhances completion for `extern` blocks.
It is recommended to reviewing the changes in order of the commits:
- The first commit (f3c4dde0a4917a2bac98605cc045eecfb4d69872) doesn’t change any logic but refactors parts of the `add_keywords` function and adds detailed comments.
- The second commit (5dcc1ab649bf8a49cadf006d620871b12f093a2f) improves completion for `extern` kw and extern blocks.
Add wrap/unwrap return type in Option
I pretty much just copied over the code and tests for wrapping/unwrapping return types in `Result` and then did a bunch of find and replace changes.
I handled unwrapping statements returning `None` by just replacing `None` with the unit type, but I'm open to suggestions for more intuitive behavior here.
Update rustc-hash to version 2
This brings in the new optimized algorithm that was shown to have small performance benefits for rustc. I haven't run the rust-analyzer benchmarks.
See https://github.com/rust-lang/rustc-hash/pull/37.
feat: initial support for safe_kw in extern blocks
This PR adds initial support for `safe` keywords in external blocks.
## Changes
1. Parsing static declarations with `safe` kw and `unsafe` kw, as well as functions with `safe` kw in extern_blocks
2. Add `HAS_SAFE_KW ` to `FnFlags`
3. Handle `safe` kw in `is_fn_unsafe_to_call` query
4. Handle safe_kw in unsafe diagnostics
internal: Fix editorconfig glob
Had been testing Zed's editorconfig branch on r-a and noticed that something was odd with yaml files.
https://spec.editorconfig.org/#glob-expressions
> {s1,s2,s3}
> any of the strings given (separated by commas, can be nested) (But {s1} only matches {s1} literally.)
LSP says about Position::character
> If the character value is greater than the line length it defaults back to the line length.
but from_proto::offset() doesn't implement this.
A client might for example request code actions for a whole line by sending
Position::character=99999. I don't think there is ever a reason (besides laziness) why the
client can't specify the line length instead but I guess we should not crash but follow protocol.
Technically it should be a warning, not an error but warning is not shown by default so keep
it at error I guess.
Fixes#18240
internal: fix lldb-dap unconditionally calling rustc
Fixes https://github.com/rust-lang/rust-analyzer/issues/18318. I also took the opportunity to refactor how `discoverSourceFileMap` worked—it now returns a type instead of mutating a map in place.
I tested this change using the LLDB DAP extension. I needed to set `"lldb-dap.executable-path": "/Applications/Xcode.app/Contents/Developer/usr/bin/lldb-dap"` for everything to work, however, but once I did, was able to successfully debug a test.
Clamp Position::character to line length
LSP says about Position::character
> If the character value is greater than the line length it defaults back to the line length.
but from_proto::offset() doesn't implement this.
A client might for example request code actions for a whole line by sending
Position::character=99999. I don't think there is ever a reason (besides laziness) why the
client can't specify the line length instead but I guess we should not crash but follow protocol.
Not sure how to update Cargo.lock (lib/README.md doesn't say how).
Fixes#18240
internal: Use local time when formatting logs
When debugging rust-analyzer and looking at logs, it's much easier to read when the timestamp is in the local timezone.
Before:
2024-08-28T20:55:38.792321Z INFO ParseQuery: invoked at R18460
After:
2024-08-28T13:55:38.792321-07:00 INFO ParseQuery: invoked at R18460
When debugging rust-analyzer and looking at logs, it's much easier to read
when the timestamp is in the local timezone.
Before:
2024-08-28T20:55:38.792321Z INFO ParseQuery: invoked at R18460
After:
2024-08-28T13:55:38.792321-07:00 INFO ParseQuery: invoked at R18460
