| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
Fix inconsistent cwd of `run` and `debug` command in client
Fix #17012. Also related to #13022 and #15993.
When the `kind` of runnable is `bin`, Cargo would use the workspace root as the cwd for the `run` command; otherwise, Cargo defaults to the package root as the cwd for `run`.
Initially, r-a assumed the workspace root as the cwd for all runnables in `debug` command, which led to issue #13022. In this case, during unit testing, the `run` command would use the package root while `debug` would use the workspace root, causing inconsistency.
PR #15993 addressed this problem by using the package root as the cwd for `debug` command. However, it also resulted in an inconsistency: when executing the `run` command within the main fn of a package (whose target is `bin`), Cargo would use the workspace root, whereas `debug` would use the package root, leading to issue #17012.
The preferable approach is to determine the cwd based on the runnable's type. To resolve this, this PR introduces a new `cwd` field within `CargoRunnable`, allowing r-a to decide the appropriate cwd depending on the specific kind of the runnable.
|
|
|
|
|
|
|
|
This reverts commit 4ca86edac97d47eecb78b16abf255950c10b67ca.
|
|
|
|
Allow sysroots to only consist of the source root dir
Fixes https://github.com/rust-lang/rust-analyzer/issues/17159
This PR encodes the `None` case of an optional sysroot into `Sysroot` itself. This simplifies a lot of things and allows us to have sysroots that consist of nothing, only standard library sources, everything but the standard library sources or everything. This makes things a lot more flexible. Additionally, this removes the workspace status bar info again, as it turns out that that can be too much information for the status bar to handle (this is better rendered somewhere else, like in the status view).
|
|
|
|
fix: Use correct toolchain channel when generating builtin type doc links
|
|
|
|
r=Veykril
Fix: infer type of async block with tail return expr
Fixes #17106
The `infer_async_block` method calls the `infer_block` method internally, which returns the never type without coercion when `tail_expr` is `None` and `ctx.diverges` is `Diverges::Always`.This is the reason for the bug in this issue.
https://github.com/rust-lang/rust-analyzer/blob/cfce2bb46da62950a8b70ddb0b2a12332da1b1e1/crates/hir-ty/src/infer/expr.rs#L1411-L1413
This PR solves the bug by adding a process to coerce after calling `infer_block` method.
This code passes all the tests, including tests I added for this isuue, however, I am not sure if this solution is right. I think that this solution is an ad hoc solution. So, I would appreciate to have your review.
I apologize if I'm off the mark, but `infer_async_block` method should be rewritten to share code with the process of infering type of `expr::Closure` instead of the `infer_block` method. That way it will be closer to the infer process of rustc.
|
|
|
|
handle {self} when removing unused imports
Fixes #17139
On master
```rs
mod inner {
pub struct X();
pub struct Y();
}
mod z {
use super::inner::{self, X}$0;
fn f() {
let y = inner::Y();
}
}
```
becomes
```rs
mod inner {
pub struct X();
pub struct Y();
}
mod z {
use super::inner:self;
fn f() {
let y = inner::Y();
}
}
```
with this fix it instead becomes
```
```rs
mod inner {
pub struct X();
pub struct Y();
}
mod z {
use super::inner;
fn f() {
let y = inner::Y();
}
}
```
|
|
davidbarsky:david/fix-completions-from-associated-types, r=Veykril
fix: ensure implied bounds from associated types are considered in autocomplete
closes: #16989
rust-analyzer needs to consider implied bounds from associated types in order to get all methods suggestions people expect. A pretty easy way to do that is to keep the `candidate_trait_id`'s receiver if it matches `TyFingerprint::Unnameable`. When benchmarking this change, I didn't notice a meaningful difference in autocomplete latency.
(`TyFingerprint::Unnameable` corresponds to `TyKind::AssociatedType`, `TyKind::OpaqueType`, `TyKind::FnDef`, `TyKind::Closure`, `TyKind::Coroutine`, and `TyKind::CoroutineWitness`.)
|
|
|
|
fix: resolve extern prelude for local mods in block modules
fix https://github.com/rust-lang/rust-analyzer/issues/17057, https://github.com/rust-lang/rust-analyzer/issues/17032.
We should use `ModuleOrigin` to check if the current module is a pseudo-module introduced by blocks (where names might be shadowed), rather than checking `block_def_map`.
|
|
davidbarsky:david/refactor-standalone-bools-into-struct, r=Veykril
internal: refactor `prefer_no_std`/`prefer_prelude` bools into a struct
I noticed that there's a large number of functions/arguments during an unrelated change that take two booleans and realized they're _probably_ better off being in a single struct—less error-prone, etc.
Feel free to suggest a better name than `ImportPathConfig`/close this entirely! I can also make these args enums; just hopefully making this a little more misuse-resistant.
|
|
|
|
|
|
|
|
fix: Various find path fixes
Fixes https://github.com/rust-lang/rust-analyzer/issues/17271
|
|
fix: Fix format_args lowering passing incorrect parameters to `rustc_parse_format`
|
|
|
|
Clear diagnostics only after new ones were received
Closes #15934
This adds a flag inside the global state which controls when old diagnostics are cleared. Now, old diagnostics should be cleared only after at least one new diagnostic is available.
|
|
feat: More callable info
With this PR we retain more info about callables other than functions, allowing for closure parameter type inlay hints to be linkable as well as better signature help around closures and `Fn*` implementors.
|
|
|
|
|
|
|
|
|
|
internal: Sync from downstream
|
|
|
|
|
|
|
|
lldb-formatters: Use StdSliceSyntheticProvider for &str
&str has associated summary provider which correctly displays string values in debugger, but while working on https://github.com/rust-lang/rust/pull/124458 I've noticed that a &str inside an enum displays a blob of memory until a 0 is reached (as a c-string) which makes a very bizarre experience when debugging
However there is already StdSliceSyntheticProvider which we use for other slices. This PR enables the same synthetic provider to be used for &str, however the summary provider is still fixed to return the string value
I've added a test `debuginfo/strings-and-strs.rs` which prior to this PR would output the following in LLDB:
```
* thread #1, name = 'a', stop reason = breakpoint 1.1
frame #0: 0x0000555555556383 a`strings_and_strs::main::h1d2b5f9227b8767d at strings-and-strs.rs:47:5
44 let plain_str = "Hello";
45 let str_in_struct = Foo { inner: "Hello" };
46 let str_in_tuple = ("Hello", "World");
-> 47 zzz(); // #break
48 }
49
50 fn zzz() {
(lldb) frame var
(alloc::string::String) plain_string = "Hello" {
vec = size=5 {
[0] = 'H'
[1] = 'e'
[2] = 'l'
[3] = 'l'
[4] = 'o'
}
}
(&str) plain_str = "Hello" {
data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py"
length = 5
}
(strings_and_strs::Foo) str_in_struct = {
inner = "Hello" {
data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py"
length = 5
}
}
((&str, &str)) str_in_tuple = {
0 = "Hello" {
data_ptr = 0x0000555555557263 "HelloWorld\U00000001gdb_load_rust_pretty_printers.py"
length = 5
}
1 = "World" {
data_ptr = 0x0000555555557268 "World\U00000001gdb_load_rust_pretty_printers.py"
length = 5
}
}
```
After this PR it would look the following way:
```
* thread #1, name = 'a', stop reason = breakpoint 1.1
frame #0: 0x0000555555556383 a`strings_and_strs::main::h1d2b5f9227b8767d at strings-and-strs.rs:47:5
44 let plain_str = "Hello";
45 let str_in_struct = Foo { inner: "Hello" };
46 let str_in_tuple = ("Hello", "World");
-> 47 zzz(); // #break
48 }
49
50 fn zzz() {
(lldb) frame var
(alloc::string::String) plain_string = "Hello" {
vec = size=5 {
[0] = 'H'
[1] = 'e'
[2] = 'l'
[3] = 'l'
[4] = 'o'
}
}
(&str) plain_str = "Hello" {
[0] = 'H'
[1] = 'e'
[2] = 'l'
[3] = 'l'
[4] = 'o'
}
(strings_and_strs::Foo) str_in_struct = {
inner = "Hello" {
[0] = 'H'
[1] = 'e'
[2] = 'l'
[3] = 'l'
[4] = 'o'
}
}
((&str, &str)) str_in_tuple = {
0 = "Hello" {
[0] = 'H'
[1] = 'e'
[2] = 'l'
[3] = 'l'
[4] = 'o'
}
1 = "World" {
[0] = 'W'
[1] = 'o'
[2] = 'r'
[3] = 'l'
[4] = 'd'
}
}
```
|
|
alloc: implement FromIterator for Box<str>
`Box<[T]>` implements `FromIterator<T>` using `Vec<T>` + `into_boxed_slice()`.
Add analogous `FromIterator` implementations for `Box<str>`
matching the current implementations for `String`.
Remove the `Global` allocator requirement for `FromIterator<Box<str>>` too.
ACP: https://github.com/rust-lang/libs-team/issues/196
|
|
Uplift more query stuff
- Uplift various query input/response internals
- Uplift the `ProofTree` structures and make the `ProofTreeBuilder` stuff (mostly) generic over `Interner`
- Stop using `TyCtxt::def_kind` in favor of `AliasTerm::kind`
r? lcnr
|
|
Rollup of 3 pull requests
Successful merges:
- #125214 (Only make GAT ambiguous in `match_projection_projections` considering shallow resolvability)
- #125236 (Add tests for `-Zunpretty=expanded` ported from stringify's tests)
- #125251 (Clarify how String::leak and into_boxed_str differ )
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
I tried to rebase this down into the first commit but it is WAY too
annoying x
|
|
|
|
|
|
|
|
and make NestedGoals generic
|
|
Clarify how String::leak and into_boxed_str differ
|
|
Add tests for `-Zunpretty=expanded` ported from stringify's tests
This PR adds a new set of tests for the AST pretty-printer.
Previously, pretty-printer edge cases were tested by way of `stringify!` in [tests/ui/macros/stringify.rs](https://github.com/rust-lang/rust/blob/1.78.0/tests/ui/macros/stringify.rs), such as the tests added by https://github.com/rust-lang/rust/commit/419b26931b73209bfafdb9938c09e12b9d650613 and https://github.com/rust-lang/rust/commit/527e2eac17c5d3709e4e30e8b72ae33a6e8990b1.
Those tests will no longer provide effective coverage of the AST pretty-printer after #124141. `Nonterminal` and `TokenKind::Interpolated` are being removed, and a consequence is that `stringify!` will perform token stream pretty printing, instead of AST pretty printing, in all of the `stringify!` cases including $:expr and all other interpolations.
This PR adds 2 new ui tests with `compile-flags: -Zunpretty=expanded`:
- **tests/ui/unpretty/expanded-exhaustive.rs** — this test aims for exhaustive coverage of all the variants of `ExprKind`, `ItemKind`, `PatKind`, `StmtKind`, `TyKind`, and `VisibilityKind`. Some parts could use being fleshed out further, but the current state is roughly on par with what exists in the old stringify-based tests.
- **tests/ui/unpretty/expanded-interpolation.rs** — this test covers tricky macro metavariable edge cases that require the AST pretty printer to synthesize parentheses in order for the printed code to be valid Rust syntax.
r? `@nnethercote`
|
|
Only make GAT ambiguous in `match_projection_projections` considering shallow resolvability
In #123537, I tweaked the hack from #93892 to use `resolve_vars_if_possible` instead of `shallow_resolve`. This considers more inference guidance ambiguous. This resulted in crater regressions in #125196.
I've effectively reverted the change to the old behavior. That being said, I don't *like* this behavior, but I'd rather keep it for now since #123537 was not meant to make any behavioral changes. See the attached example.
This also affects the new solver, for the record, which doesn't have any rules about not guiding inference from param-env candidates which may constrain GAT args as a side-effect.
r? `@lcnr` or `@jackh726`
|
|
Rename Unsafe to Safety
Alternative to #124455, which is to just have one Safety enum to use everywhere, this opens the posibility of adding `ast::Safety::Safe` that's useful for unsafe extern blocks.
This leaves us today with:
```rust
enum ast::Safety {
Unsafe(Span),
Default,
// Safe (going to be added for unsafe extern blocks)
}
enum hir::Safety {
Unsafe,
Safe,
}
```
We would convert from `ast::Safety::Default` into the right Safety level according the context.
|
|
|
|
Rollup of 4 pull requests
Successful merges:
- #125117 (Improve parser)
- #125184 (Fix ICE in non-operand `aggregate_raw_ptr` intrinsic codegen)
- #125240 (Temporarily revert to NonZeroUsize in rustc-abi to fix building on stable)
- #125248 (Migrate `run-make/rustdoc-scrape-examples-invalid-expr` to `rmake.rs`)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
|
