Fixup path fragments upon MBE transcription
Fixes#14367
There are roughly two types of paths: paths in expression context, where a separator `::` between an identifier and its following generic argument list is mandatory, and paths in type context, where `::` can be omitted.
Unlike rustc, we need to transform the parsed fragments back into tokens during transcription. When the matched path fragment is a type-context path and is transcribed as an expression-context path, verbatim transcription would cause a syntax error.
This PR fixes up path fragments by inserting `::` to make sure they are syntactically correct in all contexts. Note that this works because expression-context paths are a strict superset of type-context paths.
Add manual implementation of clone for tuples in mir interpreter
And some other minor changes.
Clone for tuple is not implemented in the std and it is magically implemented by the compiler, so we need this.
Properly infer types with type casts
This PR reenables `Expectation::Castable` (previous attempt at #14104, reverted by #14120) and implements type cast checks, which enable us to infer a bit more.
Castable expectations are relatively weak -- they only influence the inference if we cannot infer the types by other means. Therefore, we need to defer possible type unification with the casted type until we type check all expressions of the body. This PR adds a struct and slots in `InferenceContext` for the deferred cast checks (c.f. [`CastCheck`] in `rustc_hir_typeck`).
I only implemented the bits that affect the inference result. It should be possible to return type adjustments for well-formed casts and report diagnostics for invalid casts, but I'm leaving them for future work for now.
Fixes#11571Fixes#15246
[`CastCheck`]: da1d099f91/compiler/rustc_hir_typeck/src/cast.rs (L55)
vscode: change minimum VS Code version to 1.75 from 1.78
I previously mentioned [in a comment](https://github.com/rust-lang/rust-analyzer/pull/15265#issuecomment-1633240290) that folks at my employer are on 1.78, but I was incorrect: people are on 1.75. I know this is outside the standard version support policy, but I haven't seen any of the new features in VS Code be used in rust-analyzer. The most applicable feature in those three versions of VS Code that I can find [is lazily resolving code actions](https://code.visualstudio.com/updates/v1_78#_resolve-code-action-commands-in-resolvecodeaction), but it doesn't seem like rust-analyzer is making use of that feature.
(I'll be posting a PR that adds support for `$saved_file` within the next day, so feel free to bump the minimum VS Code version back to 1.78 if/when that PR lands. This just makes vendoring the _actual_ change I'm interested in a little bit easier.)
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! 🎉
