| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
This change updates the log format to use the vscode log format instead
of the custom log format, by replacing the `OutputChannel` with a
`LogOutputChannel` and using the `debug`, `info`, `warn`, and `error`
methods on it. This has the following benefits:
- Each log level now has its own color and the timestamp is in a more
standard format
- Inspect output (e.g. the log of the config object) is now colored
- Error stack traces are now shown in the output
- The log level is now controlled on the output tab by clicking the gear
icon and selecting "Debug" or by passing the `--log` parameter to
vscode. The `trace.extension` setting has been marked as deprecated.
|
|
#17497 - Invalid RA diagnostic error: expected 2 arguments, found 1
Fix for #17497
The issue occurs because in some configurations of traits where one of them has `Deref` as a supertrait, RA's type inference algorithm fails to resolve the `Deref::Target` type, and instead uses a `TyKind::BoundVar` (i.e. an unknown type). This "autoderefed" type then incorrectly acts as if it implements all traits in scope.
The fix is to re-apply the same sanity-check that is done in [`iterate_method_candidates_with_autoref()`](https://github.com/rust-lang/rust-analyzer/blob/9463d9eea4b87e651e7d8ed8425a9c92f23b1cdf/crates/hir-ty/src/method_resolution.rs#L1008), that is: don't try to resolve methods on unknown types. This same sanity-check is now done on each autoderefed type for which trait methods are about to be checked. If the autoderefed type is unknown, then the iterating of the trait methods for that type is skipped.
Includes a unit test that only passes after applying the fixes in this commit.
Includes a change to the assertion count in test `syntax_highlighting::tests::benchmark_syntax_highlighting_parser` as suggested by Lukas Wirth during review.
Includes a change to the sanity-check code as suggested by Florian Diebold during review.
|
|
The issue occurs because in some configurations of traits where one of them has Deref as a supertrait, RA's type inference algorithm fails to resolve the Deref::Target type, and instead uses a TyKind::BoundVar (i.e. an unknown type). This "autoderefed" type then incorrectly acts as if it implements all traits in scope.
The fix is to re-apply the same sanity-check that is done in iterate_method_candidates_with_autoref(), that is: don't try to resolve methods on unknown types. This same sanity-check is now done on each autoderefed type for which trait methods are about to be checked. If the autoderefed type is unknown, then the iterating of the trait methods for that type is skipped.
Includes a unit test that only passes after applying the fixes in this commit.
Includes a change to the assertion count in test syntax_highlighting::tests::benchmark_syntax_highlighting_parser as suggested by Lukas Wirth during review.
Includes a change to the sanity-check code as suggested by Florian Diebold during review.
|
|
docs: Reference cov_mark crate instead of test_utils/mark
Seems this was switched over in https://github.com/rust-lang/rust-analyzer/issues/7922
I'm guessing this should skip the changelog because it's so minor, right? Reading through https://github.com/rust-lang/rust-analyzer/blob/master/docs/dev/style.md and trying to get up to speed here =)
|
|
fix: early exit if unresolved field is an index
Fixes #17710
|
|
Seems this was switched over in https://github.com/rust-lang/rust-analyzer/issues/7922
|
|
|
|
fix: tweak hover/tooltip links
close https://github.com/rust-lang/rust-analyzer/issues/17628
|
|
|
|
fix: Fix includes not working with expr fragment inputs
Temporary workaround for https://github.com/rust-lang/rust-analyzer/issues/17701
|
|
|
|
internal: Remove unused trace module
|
|
|
|
feat: add preliminary support for `+ use<..>` `precise_capturing` syntax
## Summary
This PR adds basic support for the following syntax.
```rs
fn captures<'a: 'a, 'b: 'b, T>() -> impl Sized + use<'b, T> {}
// ~~~~~~~~~~~~~~~~~~~~~~~
// This opaque type does not capture `'a`.
fn outlives<'o, T: 'o>(_: T) {}
fn caller<'o, 'a, 'b: 'o, T: 'o>() {
// ~~
// ^ Note that we don't need `'a: 'o`.
outlives::<'o>(captures::<'a, 'b, T>());
}
```
Related to #17598
|
|
|
|
fix: Support new cargo config get env format
Fixes https://github.com/rust-lang/rust-analyzer/issues/17686
|
|
|
|
internal: Reduce size of TypeRef by 8 bytes
|
|
|
|
|
|
Remove Params and Fields from AstIdMap
These are too volatile, and the only reason for them seems to be for cfg diagnostics which does not carry the weight
|
|
|
|
|
|
|
|
|
|
internal: Fix and enable unsafe_op_in_unsafe_fn
Closes #17689
|
|
|
|
davidbarsky:david/add-more-information-to-status-command, r=Veykril
internal: add more output to the status command
Bit of a lazy change, but this is was pretty handy. I think I should clean up the configuration into something a bit more legible (maybe serialize as JSON?), but I think this is a good enough starting point that we might as well start asking people for it in issue reports.
|
|
Add method `Impl::all_in_module(…)` for allowing more localized querying
This PR is motivated by an [outside use](https://github.com/regexident/cargo-modules) of the `ra_ap_hir` crate that would benefit from being able to more efficiently query for all impls of a given module (instead of having to query for its parent crate's impls and then filtering on `impl_hir.module(db) == module_hir`).
I have the suspicion that the code as is won't quite work for file-level modules, since those don't have a block, afaict, but with all the crate-rename and version shenanigans around the `ra_ap_` release process I haven't yet been able to figure out how to patch a `ra_ap_` dependency from a third-party crate (let alone how to test this from inside of `rust-analyzer`), so haven't been able to actually run and test this. 😔
Any hints on how to make this (i.e. the code itself, as well as the testing) work are more than welcome!
|
|
minor: Read workspace root ratomls on startup
|
|
Co-authored-by: Lukas Wirth <lukastw97@gmail.com>
|
|
|
|
|
|
|
|
|
|
davidbarsky:david/remove-unindexed-project-notification, r=Veykril
chore: remove `UnindexinedProject` notification
This PR is split out from https://github.com/rust-lang/rust-analyzer/pull/17246/ (and contains its changes, which is a little annoying from a review perspective...). I'd like to land this change a week or so after #17246 lands in order to give any users of the unindexed project notification time to adopt migrate.
|
|
Summary:
Test Plan:
Reviewers:
Subscribers:
Tasks:
Tags:
|
|
minor : fixes for ratoml module
This is a follow-up PR to #17058.
- Parse errors are reflected as such by defining a new variant called `ConfigError::ParseError`
- New error collection has been added to store config level agnostic errors.
EDIT : Some things that this PR promised to solve are removed and will be addressed by other PRs
|
|
|
|
|
|
|
|
r=lnicola
Remove lens.forceCustomCommands config
Closes https://github.com/rust-lang/rust-analyzer/issues/17643
A very simple PR that removes the lens.forceCustomCommands config feature without side effects.
|
|
|
|
|
|
internal: Shrink size of `Binding`
This should save a bit of memory now that we LRU the source map
|
|
|
|
LRU `body_with_source_map` query
This query is being invalidated all the time anyways (we have an extra query on top of it for the body incrementality that is not source dependent), so there is little reason to keep these around all the time when only some IDE features are interested in them.
|
|
|
|
Remove incorrect never! invocations
These can crop up when the `Future` related lang items are missing
|
