editor/code: Break down CI steps to know what is failing easily
This do the thing I mentioned in https://github.com/rust-lang/rust-analyzer/pull/15265#issuecomment-1634424385
This aims to improve CI status check more readable.
I tried to use [`jobs.<job_id>.if`](https://docs.github.com/en/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idif) to make the configuration
more shortly once.
But it could not fire the `end-success` or `end-failure` status if some jobs in the workflow were skipped. This causes an integration problem with bors.
By their reasons, this patch still uses `jobs.<job_id>.steps[*].if`.
---
To do this change, we reorganize npm-script.
| previous | after |
|--------------------|----------------------------------------|
| `npm run lint` | `npm run lint && npm run format:check` |
| `npm run fix` | `npm run lint:fix && npm run format` |
The previous `npm run fix` sometimes does not complete fix automatically because ESLint's autofix doees not follow prettier's formatting. So we need to run `npm run lint:fix && npm run format` by this order.
To do this change, we reorganize npm-script.
| previous | after |
|--------------------|----------------------------------------|
| `npm run lint` | `npm run lint && npm run format:check` |
| `npm run fix` | `npm run lint:fix && npm run format` |
The previous `npm run fix` sometimes does not complete fix automatically
because ESLint's autofix doees not follow prettier's formatting.
So we need to run `npm run lint:fix && npm run format` by this order.
limit `change_visibility` assist to applicable items
this pr limits the `change_visibility` assist to applicable items. top level items in this context means items that are not nested within `fn`s or `trait`s.
now
```rs
fn foo {
// assists on this `struct` keyword won't include `change_visibility`
struct Bar {}
}
trait Foo {
// same with the `fn` here
fn bar();
}
```
Normalize expected ty in call arguments
fix#15321
I'm not sure if we should do this, or add a normalize in the beginning of `infer_expr_inner`, or somewhere else. r? `@lowr`
Report `incorrect-ident-case` for inner items
Fixes#15319
Although we have been collecting the diagnostics for inner items within function bodies, we were discarding them and never reported to the users. This PR makes sure that they are all reported and additionally collects the diagnostics for inner items within const bodies, static bodies, and enum variant bodies.
editor/code: [DX] Use notification command links for debugger installation
This PR improves DX (developer experience) when installing the VS Code extension for the first time. When doing so and trying to debug a Rust file, we get an error notification that either CodeLLDB or C++ extension/debugger should be installed (see image below).
<div align="center">
<img src="https://github.com/rust-lang/rust-analyzer/assets/20957750/e8ebeb1e-85f4-44e2-b79f-c48cf52e5f36" alt="Rust, prompt to install debug extension">
</div>
The PR enhances the links in the given notification and upon clicking instead of opening the Web page of the extension it installs the extension immediately, without the need to leave the editor.
Note: the feature needs to be refined, maybe an "install in progress" message or something similar, I left that for you guys to decide and implement. I think it also possible to first open the sidebar, open the Extensions tab, then run the extension installation command which would make it more user-friendly.
P.S. it is also possible to open the extension's details in VS Code directly via the same links and then the user would have to manually click on the Install button - if installation is not the desired behavior.
Happy coding! 🎉
Pass `TraitEnvironment` into `layout_ty` and `const_eval`
We need to do either this or get rid of trait environment in `normalize_ty`. Let's go with this for now.
Don't follow raw pointer derefs when considering method receiver candidates
In https://github.com/rust-lang/rust-analyzer/pull/15118, I enabled following raw pointer derefs when considering self type candidates. However, I also inadvertently enabled it for receiver type candidates, which is invalid and causes false positives (see new test).
Support reading uncompressed proc macro metadata
rust-lang/rust#113695 makes the dylib metadata uncompressed for perf reasons. This commit allows reading both the current compressed and future uncompressed dylib metadata.
rust-lang/rust#113695 makes the dylib metadata uncompressed for perf
reasons. This commit allows reading both the current compressed and
future uncompressed dylib metadata.
