Previously, annotations would only appear above the name of an item (function signature, struct declaration, etc).
Now, rust-analyzer can be configured to show annotations either above the name or above the whole item (including doc comments and attributes).
Build release artifact against older Glibc
When GitHub [deprecated Ubuntu 18.04](https://github.blog/changelog/2022-08-09-github-actions-the-ubuntu-18-04-actions-runner-image-is-being-deprecated-and-will-be-removed-by-12-1-22/) runners, rust-analyzer was forced to bump runners to 20.04 which includes an updated Glib. This renders RA incompatible with the still popular Ubuntu 18.04 and other slightly older distro versions.
Until a deprecation plan is announced on RA's side, I propose binaries shall be built against older glibc to maintain compatibility.
This PR changes the Release CI workflow to build the `linux-x64/x86_64-unknown-linux-gnu` release in an Ubuntu 18.04 container.
Fixes#13081 and #13085
Use proc-macro-srv from sysroot in rust-project.json workspaces
This was discussed [on zulip](https://rust-lang.zulipchat.com/#narrow/stream/185405-t-compiler.2Frust-analyzer/topic/.60sysroot.60.20vs.20.60sysroot_src.60.20for.20.60rust-project.2Ejson.60.3F/near/293023920), basically in `rust-project.json` workspaces RA doesn't respect the `sysroot` setting when picking which `proc-macro-srv` to launch, and this causes abi mismatches in practice.
This is the simple fix that `@Veykril` suggested, and I've verified that it works on Fuchsia by inspecting the cmdline with `pgrep rust-analyzer | xargs ps -fp` to check that it's using the `proc-macro-srv` from our prebuilts which matches the `sysroot` specified in our `rust-project.json`.
Can this be merged as is, or do we need to add tests that exercise this?
fix: sort all bounds on trait object types
Fixes#13181#12793 allowed different ordering of trait bounds in trait object types but failed to account for the ordering of projection bounds. I opted for sorting all the bounds at once rather than splitting them into `SmallVec`s so it's easier to do the same thing for other bounds when we have them.
fix: Insert whitespaces into static & const bodies if they are expanded from macro on hover
Partially fixes#13143.
To resolve the other part we need to expand macros in unevaluated static & const bodies, and I'm not sure we want to. If for example it includes a call to `assert!()`, expanding it will lead to worse hover.
fix: correct broken logic for return complition
It seems that we've accidentally deleted the tests here couple of years
ago, and then fairly recently made a typo during refactor as well.
Reinstall tests, with coverage marks this time :-)
It seems that we've accidentally deleted the tests here couple of years
ago, and then fairly recently made a typo during refactor as well.
Reinstall tests, with coverage marks this time :-)
Lift out the module scope into a field in the Resolver
A Resolver *always* has a module scope at the end of its scope stack,
instead of encoding this as an invariant we can just lift this scope
out into a field, allowing us to skip going through the scope vec
indirection entirely.
A Resolver *always* has a module scope at the end of its scope stack,
instead of encoding this as an invariant we can just lift this scope
out into a field, allowing us to skip going through the scope vec
indirection entirely.
feat: Implement `feature(exhaustive_patterns)` from unstable Rust
Closes#12753
Recognize Rust's unstable `#![feature(exhaustive_patterns)]` (RFC 1872). Allow omitting visibly uninhabited variants from `match` expressions when the feature is on.
This adjusts match checking to the current implementation of the postponed RFC 1872 in rustc.
fix: Parse TypePathFn with preceding `::`
e.g. `impl Fn::() -> ()`.
Fixes#13157. This was the problem, not that the path was not at the end.
I could unify the parsing of `::` of TypePathFn with that of generic arg list, but some code relies on the `::` of generic arg list to be inside it.
fix: Lower float literals with underscores
Fixes#13155 (the problem was the `PI` is defined with `_f64` suffix). `PI` is still truncated, though, because `f64` cannot represent the value with full precision.
Properly handle break resolution inside non-breakable expressions
We now diagnose invalid `continue` expressions and properly handle things like `async` blocks which prevent labels from resolving further. Cleaned this up since `label_break_value` is on the way to stabilization in rust (🎉 finally) and we weren't handling breaks for blocks properly yet.
