| Age | Commit message (Collapse) | Author | Lines |
|---|
|
|
|
|
|
|
|
fix: Apply `IndexMut` obligations for non-assigning mutable index usages
Fixes #17738
Currently, we are pushing `IndexMut` obligations only for assign usages;
https://github.com/rust-lang/rust-analyzer/blob/f982f3fa2c23570c10108e83c1ecc392ea411866/crates/hir-ty/src/infer/expr.rs#L809-L817
|
|
|
|
|
|
davidbarsky:david/remove-abspath-requirement-in-linked-projects, r=Veykril
fix: remove AbsPath requirement from linkedProjects
Should (fingers crossed!) fix https://github.com/rust-lang/rust-analyzer/issues/17664. I opened the `rustc` workspace with the [suggested configuration](https://github.com/rust-lang/rust/blob/e552c168c72c95dc28950a9aae8ed7030199aa0d/src/etc/rust_analyzer_settings.json) and I was able to successfully open some rustc crates (`rustc_incremental`) and have IDE functionality.
`@Veykril:` can you try these changes and let me know if it fixed rustc?
|
|
|
|
fix: Errors on method call inferences with elided lifetimes
Fixes #17734
Currently, we are matching non-lifetime(type or const) generic arg to liftime argument position while building substs for method calling when there are elided lifetimes.
This mismatch just make a subst for error lifetime and while this alone is not much a trouble, it also makes the mismatched type or const generic arg cannot be used in its proper place and this makes type inference failure
|
|
|
|
|
|
minor: Set tracing level to debug when `cargo config get env` fails
fixes #17739
|
|
|
|
feat: Introduce workspace `rust-analyzer.toml`s
In order to globally configure a project it was, prior to this PR, possible to have a `ratoml` at the root path of a project. This is not the case anymore. Instead we now let ratoml files that are placed at the root of any workspace have a new scope called `workspace`. Although there is not a difference between a `workspace` scope and and a `global` scope, future PRs will change that.
|
|
fix: Fix incorrect retrying of inlay hint requests
|
|
|
|
fix: Fix builtin includes rejecting raw string literals
Fixes https://github.com/rust-lang/rust-analyzer/issues/17701
|
|
|
|
|
|
feat: Use spans for builtin and declarative macro expansion errors
This should generally improve some error reporting for macro expansion errors. Especially for `compile_error!` within proc-macros
|
|
|
|
|
|
feat(ide-completion): explictly show `async` keyword on `impl trait` methods
OLD:
<img width="676" alt="image" src="https://github.com/user-attachments/assets/f6fa626f-6b6d-4c22-af27-b0755e7a6bf8">
Now:
<img width="684" alt="image" src="https://github.com/user-attachments/assets/efbaac0e-c805-4dd2-859d-3e44b2886dbb">
---
This is an preparation for https://github.com/rust-lang/rust-analyzer/issues/17719.
```rust
use std::future::Future;
trait DesugaredAsyncTrait {
fn foo(&self) -> impl Future<Output = usize> + Send;
fn bar(&self) -> impl Future<Output = usize> + Send;
}
struct Foo;
impl DesugaredAsyncTrait for Foo {
fn foo(&self) -> impl Future<Output = usize> + Send {
async { 1 }
}
//
async fn bar(&self) -> usize {
1
}
}
fn main() {
let fut = Foo.bar();
fn _assert_send<T: Send>(_: T) {}
_assert_send(fut);
}
```
If we don't distinguish `async` or not. It would be confusing to generate sugared version `async fn foo ....` and original form `fn foo` for `async fn in trait` that is defined in desugar form.
|
|
|
|
|
|
This reverts commit 752c49b679afcec7edf5d26d52bf3d164ee7349f.
|
|
fix: let glob imports override other globs' visibility
Follow up to #14930
Fixes #11858
Fixes #14902
Fixes #17704
I haven't reworked the code here at all - I don't feel confident in the codebase to do so - just rebased it onto the current main branch and fixed conflicts.
I'm not _entirely_ sure I understand the structure of the `check` function in `crates/hir-def/src/nameres` tests. I think the change to the test expectation from #14930 is correct, marking the `crate::reexport::inner` imports with `i`, and I understand it to mean there's a specific token in the import that we can match it to (in this case, `Trait`, `function` and `makro` of `pub use crate::defs::{Trait, function, makro};` respectively), but I had some trouble understanding the meaning of the different parts of `PerNs` to be sure.
Does this make sense?
I tested building and using RA locally with `cargo xtask install` and after this change the documentation for `arrow_array::ArrowPrimitiveType` seems to be picked up correctly!
|
|
feat: use vscode log format for client logs
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.
Motivation:
The large uncolored unformatted log output with a large config object logged whenever it changes has always dominated the logs. This subjectively has made it that looking to see what the client is doing has always been a bit disappointing. That said, there's only 17 log messages total in the client. Hopefully by making the logs more visually useful this will encourage adding more appropriate debug level messages in future.
Incidentally, it might be worth only logging the config change message at a debug level instead of an info level to reduce the noise.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
minor: sync from downstream
|
|
|
|
|
|
Bootstrap command refactoring: make command output API more bulletproof (step 7)
Continuation of https://github.com/rust-lang/rust/pull/127680.
This PR modifies the API of running commands to make it more explicit when a command is expected to produce programmatically handled output. Now if you call just `run`, you cannot access the stdout/stderr by accident, because it will not be returned to the caller.
This API change might be seen as overkill, let me know what do you think. In any case, I'd like to land the second commit, to make it harder to accidentally read stdout/stderr of commands that did not capture output (now you'd get an empty string as a result, but you should probably get a panic instead, if you try to read uncaptured stdout/stderr).
Tracking issue: https://github.com/rust-lang/rust/issues/126819
r? `@onur-ozkan`
try-job: x86_64-msvc
|
|
Rollup of 5 pull requests
Successful merges:
- #127853 (`#[naked]`: report incompatible attributes)
- #128276 (Add a README to rustbook to explain its purpose)
- #128279 (Stabilize `is_sorted`)
- #128282 (bitwise and bytewise methods on `NonZero`)
- #128285 (rustc book: document how the RUST_TARGET_PATH variable is used)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
flip the naming of the doc comment to comment assist
I did this the wrong way around when I implemented these assists, so here is a quick fix for it
|
|
#17470 - run unit tests at the crate level not workspace
For https://github.com/rust-lang/rust-analyzer/issues/17470
Use the test path to identify a package in the workspace and run the unit test there instead of at the workspace.
|
|
rustc book: document how the RUST_TARGET_PATH variable is used
based on the module comment in
rust/compiler/rustc_target/src/spec/mod.rs
Fixes #128280
|
|
bitwise and bytewise methods on `NonZero`
Implementation for `nonzero_bitwise`
Tracking issue #128281
ACP https://github.com/rust-lang/libs-team/issues/413
|
|
Stabilize `is_sorted`
Closes: https://github.com/rust-lang/rust/issues/53485.
~~Question: does~~ https://github.com/rust-lang/rust/blob/8fe0c753f23e7050b87a444b6622caf4d2272d5d/compiler/rustc_lint_defs/src/builtin.rs#L1986-L1994 ~~need a new example?~~
edit: It causes a test failure and needs to be changed anyway.
``@rustbot`` label: +T-libs-api
r? libs-api
|
|
Add a README to rustbook to explain its purpose
This adds a README to the rustbook tool to help explain what it is for and how to use it.
|
|
`#[naked]`: report incompatible attributes
tracking issue: https://github.com/rust-lang/rust/issues/90957
this is a re-implementation of https://github.com/rust-lang/rust/pull/93809 by ``@bstrie`` which was closed 2 years ago due to inactivity.
This PR takes some of the final comments into account, specifically providing a little more context in error messages, and using an allow list to determine which attributes are compatible with `#[naked]`.
Notable attributes that are incompatible with `#[naked]` are:
* `#[inline]`
* `#[track_caller]`
* ~~`#[target_feature]`~~ (this is now allowed, see PR discussion)
* `#[test]`, `#[ignore]`, `#[should_panic]`
These attributes just directly conflict with what `#[naked]` should do.
Naked functions are still important for systems programming, embedded, and operating systems, so I'd like to move them forward.
|
|
r=Noratrieb
trans her gender
CC https://github.com/rust-lang/team/pull/1511
r? `@Noratrieb`
|
|
extra_test_bin_args settings
|
|
|
|
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.
|
