| Age | Commit message (Collapse) | Author | Lines |
|---|
|
Update cc to 1.1.22
This version of `cc` contains [a fix](https://github.com/rust-lang/cc-rs/releases/tag/cc-v1.1.22) to prevent spurious rebuilds. Hopefully this should help avoid the CI issues rustc has been having.
|
|
|
|
Building before a debugging session was restarted
# Background
Resolves #17901. It adds support for rebuilding after debugging a test was restarted. This means the test doesn't have to be aborted and manually re-ran again.
# How this is tested
First, all the Visual Studio Code extensions are loaded into an Extension Host window. Then, a sample test like below was ran and restarted to see if it was correctly rebuild.
```rust
#[test]
fn test_x() {
assert_eq!("1.1.1", "1.1.0");
}
```
|
|
internal: Add `SyntaxFactory` to ease generating nodes with syntax mappings
Part of [#15710](https://github.com/rust-lang/rust-analyzer/issues/15710)
Instead of requiring passing a `&mut SyntaxEditor` to every make constructor to generate mappings, we instead wrap that logic in `SyntaxFactory`, and afterwards add all the mappings to the `SyntaxEditor`.
Includes an example of using `SyntaxEditor` & `SyntaxFactory` in the `extract_variable` assist.
|
|
minor: Stricter requirements for package wide flycheck
Require the existence of a target and `check_workspace` to be false to restart package-wide flycheck. Fixes #18194 , #18104
|
|
false to restart package-wide flycheck
|
|
|
|
|
|
fix: Don't report a startup error when a discover command is configured
Previously, r-a would show an error if both fetch_workspaces_queue and discover_workspace_queue were empty. We're in this state at startup, so users would see an error if they'd configured
discover_workspace_config.
Instead, allow the fetch_workspaces_queue to have zero items if discover_workspace_config is set.
Whilst we're here, prefer "failed to fetch" over "failed to discover", so the error message better reflects what this function is doing.
|
|
Previously, r-a would show an error if both fetch_workspaces_queue and
discover_workspace_queue were empty. We're in this state at startup,
so users would see an error if they'd configured
discover_workspace_config.
Instead, allow the fetch_workspaces_queue to have zero items if
discover_workspace_config is set.
Whilst we're here, prefer "failed to fetch" over "failed to discover",
so the error message better reflects what this function is doing.
|
|
Require rust 1.81
rust-analyzer doesn't build on 1.80 because we use `#[expect(lint)]`:
```
error[E0658]: the `#[expect]` attribute is an experimental feature
--> crates/hir-expand/src/prettify_macro_expansion_.rs:11:1
|
11 | #[expect(deprecated)]
| ^^^^^^^^^^^^^^^^^^^^^
|
= note: see issue #54503 <https://github.com/rust-lang/rust/issues/54503> for more information
```
|
|
|
|
feat: Index workspace symbols at startup rather than on the first symbol search.
This will eliminate potential many-second delays when performing the first search, at the price of making cache priming (“Indexing N/M” in the VS Code status bar) take a little longer in total. Hopefully this additional time is insignificant because a typical session will involve at least one symbol search.
Further improvement would be to do this as a separate parallel task (which will be beneficial if the workspace contains a small number of large crates), but that would require significant additional refactoring of the progress-reporting mechanism to understand multiple tasks per crate. Happy to tackle that in this PR if desired, but I thought I'd propose the minimal change first.
|
|
internal: add tracing to project discovery and VFS loading
With `"env RA_PROFILE=vfs_load|parallel_prime_caches|discover_command>500`, this results in the following output:
```
21888ms discover_command
11627ms vfs_load @ total = 701
1503ms vfs_load @ total = 701
30211ms parallel_prime_caches
```
As a followup, I'd like to make hprof emit the information above as JSON.
|
|
|
|
|
|
|
|
internal: Sync from downstream
|
|
fix: Pass all-targets for build scripts in more cli commands
Without this, build scripts don't run for tests and as such any proc-macros in dev-deps fail to resolve
|
|
|
|
Without this, build scripts don't run for tests and as such any proc-macros in dev-deps fail to resolve
|
|
|
|
|
|
|
|
|
|
Rollup of 7 pull requests
Successful merges:
- #130234 (improve compile errors for invalid ptr-to-ptr casts with trait objects)
- #130752 (Improve assembly test for CMSE ABIs)
- #130764 (Separate collection of crate-local inherent impls from error tracking)
- #130788 (Pin memchr to 2.5.0 in the library rather than rustc_ast)
- #130789 (add InProgress ErrorKind gated behind io_error_inprogress feature)
- #130793 (Mention `COMPILETEST_VERBOSE_CRASHES` on crash test failure)
- #130798 (rustdoc: inherit parent's stability where applicable)
Failed merges:
- #130735 (Simple validation for unsize coercion in MIR validation)
r? `@ghost`
`@rustbot` modify labels: rollup
|
|
rustdoc: inherit parent's stability where applicable
It is currently not possible for a re-export to have a different stability (https://github.com/rust-lang/rust/issues/30827). Therefore the standard library uses a hack when moving items like `std::error::Error` or `std::net::IpAddr` into `core` by marking the containing module (`core::error` / `core::net`) as unstable or stable in a later version than the items the module contains.
Previously, rustdoc would always show the *stability as declared* for an item rather than the *stability as publicly reachable* (i.e. the features required to actually access the item), which could be confusing when viewing the docs. This PR changes it so that we show the stability of the first unstable parent or the most recently stabilized parent instead, to hopefully make things less confusing.
fixes https://github.com/rust-lang/rust/issues/130765
screenshots:
 
|
|
Mention `COMPILETEST_VERBOSE_CRASHES` on crash test failure
Fixes https://github.com/rust-lang/rust/issues/130776.
r? `@matthiaskrgr` (or compiler/bootstrap)
|
|
add InProgress ErrorKind gated behind io_error_inprogress feature
Follow up on https://github.com/rust-lang/libs-team/issues/92#issuecomment-2371666560
|
|
Pin memchr to 2.5.0 in the library rather than rustc_ast
The latest versions of `memchr` experience LTO-related issues when compiling for windows-gnu [1], so needs to be pinned. The issue is present in the standard library.
`memchr` has been pinned in `rustc_ast`, but since the workspace was recently split, this pin no longer has any effect on library crates.
Resolve this by adding `memchr` as an _unused_ dependency in `std`, pinned to 2.5. Additionally, remove the pin in `rustc_ast` to allow non-library crates to upgrade to the latest version.
Link: https://github.com/rust-lang/rust/issues/127890 [1]
try-job: x86_64-mingw
try-job: x86_64-msvc
|
|
Separate collection of crate-local inherent impls from error tracking
#119895 changed the return type of the `crate_inherent_impls` query from `CrateInherentImpls` to `Result<CrateInherentImpls, ErrorGuaranteed>` to avoid needing to use the non-parallel-friendly `track_errors()` to track if an error was reporting from within the query... This was mostly fine until #121113, which stopped halting compilation when we hit an `Err(ErrorGuaranteed)` in the `crate_inherent_impls` query.
Thus we proceed onwards to typeck, and since a return type of `Result<CrateInherentImpls, ErrorGuaranteed>` means that the query can *either* return one of "the list inherent impls" or "error has been reported", later on when we want to assemble method or associated item candidates for inherent impls, we were just treating any `Err(ErrorGuaranteed)` return value as if Rust had no inherent impls defined anywhere at all! This leads to basically every inherent method call failing with an error, lol, which was reported in #127798.
This PR changes the `crate_inherent_impls` query to return `(CrateInherentImpls, Result<(), ErrorGuaranteed>)`, i.e. returning the inherent impls collected *and* whether an error was reported in the query itself. It firewalls the latter part of that query into a new `crate_inherent_impls_validity_check` just for the `ensure()` call.
This fixes #127798.
|
|
Improve assembly test for CMSE ABIs
Tracking issues: #75835 #81391
This ensures the code-gen for these ABIs does not change silently. There is a small chance that this code-gen might change, however even GCC (https://godbolt.org/z/16arxab5x and https://godbolt.org/z/16arxab5x) generates almost the same assembly for these ABIs. I hope the notes in the comments should help fix the tests if it ever breaks.
|
|
improve compile errors for invalid ptr-to-ptr casts with trait objects
This is a follow-up to https://github.com/rust-lang/rust/pull/120248 to improve some of its error messages.
1. Make the borrowcheck error for "type annotation requires that x must outlive y" actually point at the type annotation, i.e. the type `T` in a `x as T` cast. This makes the error more consistent with other errors caused by type annotation in other places, such as
```text
error: lifetime may not live long enough
--> src/lib.rs:4:12
|
3 | fn bar(a: &i32) {
| - let's call the lifetime of this reference `'1`
4 | let b: &'static i32 = a;
| ^^^^^^^^^^^^ type annotation requires that `'1` must outlive `'static`
```
2. Don't say "cast" when we actually mean "coercion" and give borrowcheck errors from actual casts (which is currently just the check added in https://github.com/rust-lang/rust/pull/120248) a higher priority than ones from coercions. This can improve the errors for ptr-to-ptr cast between trait objects because they are are lowered as an upcast "unsizing" coercion if possible (which may be the identity upcast) followed by the actual cast.
3. Bring back the old "casting X as Y is invalid" message for type mismatch in the principals and reword the "vtable kinds may not match" message to more accurately describe the pointer metadata and not refer to "vtables" if the metadata is unknown.
fixes https://github.com/rust-lang/rust/issues/130030
r? `@WaffleLapkin` but feel free to reassign
|
|
Fix cargo staging for run-make tests
Follow-up to https://github.com/rust-lang/rust/pull/130642#issuecomment-2366891866 to make sure that when
```
$ COMPILETEST_FORCE_STAGE0=1 ./x test run-make --stage 0
```
is used, bootstrap cargo is used in order to avoid building stage 1 rustc. Note that run-make tests are usually not written with `--stage 0` in mind and some tests may rely on stage1 rustc (nightly) behavior, and it is expected that some tests will fail under this invocation.
This PR also fixes `tool::Cargo` staging in compiletest when preparing for `run-make` test mode, by chopping off a stage from the `compiler` passed to `tool::Cargo` such that when the user invokes with stage `N`
```
./x test run-make --stage N
```
the `run-make` test suite will be tested against the cargo built by stage `N` compiler. Let's take `N=1`, i.e. `--stage 1`, without chopping off a stage, previously `./x test run-make --stage 1` will cause stage 1 rustc + std to be built, then stage 2 rustc, and cargo will be produced by the stage 2 rustc, which is clearly not what we want. By chopping off a stage, it means that cargo will be produced by the stage 1 rustc.
cc #119946, #59864.
See discussions regarding the tool staging at https://rust-lang.zulipchat.com/#narrow/stream/326414-t-infra.2Fbootstrap/topic/.E2.9C.94.20stage1.20run-make.20tests.20now.20need.20stage2.20rustc.20built.20for.20c.2E.2E.2E.
|
|
|
|
|
|
|
|
This changes the remaining span for the cast, because the new `Cast`
category has a higher priority (lower `Ord`) than the old `Coercion`
category, so we no longer report the region error for the "unsizing"
coercion from `*const Trait` to itself.
|
|
|
|
|
|
|
|
r=cuviper
Add `optimize_for_size` variants for stable and unstable sort as well as select_nth_unstable
- Stable sort uses a simple merge-sort that re-uses the existing - rather gnarly - merge function.
- Unstable sort jumps directly to the branchless heapsort fallback.
- select_nth_unstable jumps directly to the median_of_medians fallback, which is augmented with a custom tiny smallsort and partition impl.
Some code is duplicated but de-duplication would bring it's own problems. For example `swap_if_less` is critical for performance, if the sorting networks don't inline it perf drops drastically, however `#[inline(always)]` is also a poor fit, if the provided comparison function is huge, it gives the compiler an out to only instantiate `swap_if_less` once and call it. Another aspect that would suffer when making `swap_if_less` pub, is having to cfg out dozens of functions in in smallsort module.
Part of https://github.com/rust-lang/rust/issues/125612
r? `@Kobzol`
|
|
|
|
Co-authored-by: David Tolnay <dtolnay@gmail.com>
Co-authored-by: nora <48135649+Noratrieb@users.noreply.github.com>
|
|
|
|
The latest versions of `memchr` experience LTO-related issues when
compiling for windows-gnu [1], so needs to be pinned. The issue is
present in the standard library.
`memchr` has been pinned in `rustc_ast`, but since the workspace was
recently split, this pin no longer has any effect on library crates.
Resolve this by adding `memchr` as an _unused_ dependency in `std`,
pinned to 2.5. Additionally, remove the pin in `rustc_ast` to allow
non-library crates to upgrade to the latest version.
Link: https://github.com/rust-lang/rust/issues/127890 [1]
|
|
fix: Temporary fix for `remove_unused_imports` not handling import aliases correctly
Fixes #18129
|
|
Revert "Apply EarlyOtherwiseBranch to scalar value #129047"
This reverts PR #129047, commit a772336fb3fbd1fe4493077fcfe04e0221296a99, reversing changes made to 702987f75b74f789ba227ee04a3d7bb1680c2309.
cc `@DianQK` and `@cjgillot` as the PR author and reviewer of #129047 respectively.
It seems [Apply EarlyOtherwiseBranch to scalar value #129047](https://github.com/rust-lang/rust/pull/129047) may have lead to several nightly regressions:
- https://github.com/rust-lang/rust/issues/130769
- https://github.com/rust-lang/rust/issues/130774
- https://github.com/rust-lang/rust/issues/130771
Example test that would ICE with changes in #129047 (this test is included in this PR):
```rs
//@ compile-flags: -C opt-level=3
//@ check-pass
use std::task::Poll;
pub fn poll(val: Poll<Result<Option<Vec<u8>>, u8>>) {
match val {
Poll::Ready(Ok(Some(_trailers))) => {}
Poll::Ready(Err(_err)) => {}
Poll::Ready(Ok(None)) => {}
Poll::Pending => {}
}
}
```
Since this is a mir-opt ICE that seems to quite easy to trigger with real-world crates being affected, let's revert for now and reland the mir-opt after these are fixed.
|
|
correctly
|
|
|
