Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 11 pull requests #129810

Closed
wants to merge 234 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

Failed merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

alibektas and others added 30 commits August 1, 2024 02:38
Add an explanatory sentence and some sample code to help
readers understand why this struct exists.
minor: Add a doc comment for OpQueue

Add an explanatory sentence and some sample code to help readers understand why this struct exists.
…ebold

internal: Be more resilient to bad language item definitions in binop inference

Fixes rust-lang#16287
Fixes rust-lang#16286

There's one more in `write_fn_trait_method_resolution`, but I'm not sure if it won't cause further problems in `infer_closures`.
fix: Panic while canonicalizing erroneous projection type

Fixes rust-lang#17866

The root cause of rust-lang#17866 is quite horrifyng 😨

```rust
trait T {
    type A;
}

type Foo = <S as T>::A; // note that S isn't defined

fn main() {
    Foo {}
}
```

While inferencing alias type `Foo = <S as T>::A`;

https://github.com/rust-lang/rust-analyzer/blob/78c2bdce860dbd996a8083224d01a96660dd6a15/crates/hir-ty/src/infer.rs#L1388-L1398

the error type `S` in it is substituted by inference var in L1396 above as below;

https://github.com/rust-lang/rust-analyzer/blob/78c2bdce860dbd996a8083224d01a96660dd6a15/crates/hir-ty/src/infer/unify.rs#L866-L869

This new inference var's index is `1`, as the type inferecing procedure here previously inserted another inference var into same `InferenceTable`.

But after that, the projection type made from the above then passed to the following function;

https://github.com/rust-lang/rust-analyzer/blob/78c2bdce860dbd996a8083224d01a96660dd6a15/crates/hir-ty/src/traits.rs#L88-L96

here, a whole new `InferenceTable` is made, without any inference var and in the L94, this table calls;

https://github.com/rust-lang/rust-analyzer/blob/78c2bdce860dbd996a8083224d01a96660dd6a15/crates/hir-ty/src/infer/unify.rs#L364-L370

And while registering `AliasEq` `obligation`, this obligation contains inference var `?1` made from the previous table, but this table has only one inference var `?0` made at L365.
So, the chalk panics when we try to canonicalize that obligation to register it, because the obligation contains an inference var `?1` that the canonicalizing table doesn't have.

Currently, we are calling `InferenceTable::new()` to do some normalizing, unifying or coercing things to some targets that might contain inference var that the new table doesn't have.
I think that this is quite dangerous footgun because the inference var is just an index that does not contain the information which table does it made from, so sometimes this "foreign" index might cause panic like this case, or point at the wrong variable.

This PR mitigates such behaviour simply by inserting sufficient number of inference vars to new table to avoid such problem.
This strategy doesn't harm current r-a's intention because the inference vars that passed into new tables are just "unresolved" variables in current r-a, so this is just making sure that such "unresolved" variables exist in the new table
fix: Panic while hovering associated function with type annotation on generic param that not inherited from its container type

Fixes rust-lang#17871

We call `generic_args_sans_defaults` here;

https://github.com/rust-lang/rust-analyzer/blob/64a140527b383e3a2fe95908881624fc5374c60c/crates/hir-ty/src/display.rs#L1021-L1034

but the following substitution inside that function panic in rust-lang#17871;

https://github.com/rust-lang/rust-analyzer/blob/64a140527b383e3a2fe95908881624fc5374c60c/crates/hir-ty/src/display.rs#L1468

it's because the `Binders.binder` inside `default_parameters` has a same length with the generics of the function we are hovering on, but the generics of it is split into two, `fn_params` and `parent_params`.
Because of this, it may panic if the function has one or more default parameters and both `fn_params` and `parent_params` are non-empty, like the case in the title of this PR.

So, we must call `generic_args_sans_default` first and then split it into `fn_params` and `parent_params`
…kril

internal: Properly check the edition for edition dependent syntax kinds

This puts the current edition in a bunch of places, most of which I annoted with FIXMEs asside from the ones in ide-assists because I couldnt bother with those
Assuming it isn't cancelled. Closes rust-lang#17902.

The only place CommandHandle::join is used is when the flycheck command
finishes, so this commit changes the behavior of the method itself.
…zyCell/Lock

This doesn't get rid of the once_cell dependency, unfortunately, since we have dependencies that use it, but it's a nice to do cleanup. And when our deps will eventually get rid of once_cell we will get rid of it for free.
This speeds up short identifiers search significantly, while unlikely to have an effect on long identifiers (the analysis takes much longer than some character comparison).

Tested by finding all references to `eq()` (from `PartialEq`) in the rust-analyzer repo. Total time went down from 100s to 10s (a 10x reduction!).
internal: Replace once_cell with std's recently stabilized OnceCell/Lock and LazyCell/Lock

This doesn't get rid of the once_cell dependency, unfortunately, since we have dependencies that use it, but it's a nice to do cleanup. And when our deps will eventually get rid of once_cell we will get rid of it for free.
…s, r=Veykril

Test for word boundary in `FindUsages`

This speeds up short identifiers search significantly, while unlikely to have an effect on long identifiers (the analysis takes much longer than some character comparison).

Tested by finding all references to `eq()` (from `PartialEq`) in the rust-analyzer repo. Total time went down from 100s to 10s (a 10x reduction!).

Feel free to close this if you consider this a non-issue, as most short identifiers are local.
Allow flycheck process to exit gracefully

Assuming it isn't cancelled. Closes rust-lang#17902.

The only place CommandHandle::join() is used is when the flycheck command
finishes, so this commit changes the behavior of the method itself.

The only reason I can see for the existing behavior is if the command is somehow holding onto a build lock longer than it should, this would force it to be released. But it would be a pretty heavy-handed way to solve that issue. I'm not aware of this occurring in practice.
This PR touches a lot of parts. But the main changes are changing
`hir_expand::Name` to be raw edition-dependently and only when necessary
(unrelated to how the user originally wrote the identifier),
and changing `is_keyword()` and `is_raw_identifier()` to be edition-aware
(this was done in rust-lang#17896, but the FIXMEs were fixed here).

It is possible that I missed some cases, but most IDE parts should properly
escape (or not escape) identifiers now.

The rules of thumb are:

 - If we show the identifier to the user, its rawness should be determined
   by the edition of the edited crate. This is nice for IDE features,
   but really important for changes we insert to the source code.
 - For tests, I chose `Edition::CURRENT` (so we only have to (maybe) update
   tests when an edition becomes stable, to avoid churn).
 - For debugging tools (helper methods and logs), I used `Edition::LATEST`.
…-keyword, r=Veykril

fix: Properly account for editions in names

This PR touches a lot of parts. But the main changes are changing `hir_expand::Name` to be raw edition-dependently and only when necessary (unrelated to how the user originally wrote the identifier), and changing `is_keyword()` and `is_raw_identifier()` to be edition-aware (this was done in rust-lang#17896, but the FIXMEs were fixed here).

It is possible that I missed some cases, but most IDE parts should properly escape (or not escape) identifiers now.

The rules of thumb are:

 - If we show the identifier to the user, its rawness should be determined by the edition of the edited crate. This is nice for IDE features, but really important for changes we insert to the source code.
 - For tests, I chose `Edition::CURRENT` (so we only have to (maybe) update tests when an edition becomes stable, to avoid churn).
 - For debugging tools (helper methods and logs), I used `Edition::LATEST`.

Reviewing notes:

This is a really big PR but most of it is mechanical translation. I changed `Name` displayers to require an edition, and followed the compiler errors. Most methods just propagate the edition requirement. The interesting cases are mostly in `ide-assists`, as sometimes the correct crate to fetch the edition from requires awareness (there may be two). `ide-completions` and `ide-diagnostics` were solved pretty easily by introducing an edition field to their context. `ide` contains many features, for most of them it was propagated to the top level function and there the edition was fetched based on the file.

I also fixed all FIXMEs from rust-lang#17896. Some required introducing an edition parameter (usually not for many methods after the changes to `Name`), some were changed to a new method `is_any_identifier()` because they really want any possible keyword.

Fixes rust-lang#17895.
Fixes rust-lang#17774.
…r=davidbarsky

Add scip/lsif flag to exclude vendored libaries

rust-lang#17809 changed StaticIndex to include vendored libraries. This PR adds a flag to disable that behavior.

At work, our monorepo has too many rust targets to index all at once, so we split them up into several shards. Since all of our libraries are vendored, if rust-analyzer includes them, sharding no longer has much benefit, because every shard will have to index the entire transitive dependency graphs of all of its targets. We get around the issue presented in rust-lang#17809 because some other shard will index the libraries directly.
…, r=lnicola

Remove rust-analyzer.workspace.discoverProjectRunner

The functionality for this vscode config option was removed in rust-lang#17395, so it doesn't do anything anymore.
Pin `rowan` to `0.15.15`

To prevent rust-lang#17914, I think that it would be safer pinning this before we fix it correctly
llvm-wrapper: adapt for LLVM API changes

No functional changes intended.

Updates the wrapper for 5c4lar/llvm-project@21eddfa.

```@rustbot``` label: +llvm-main
r? ```@nikic```
…ler-errors

Add a test for trait solver overflow in MIR inliner cycle detection

This test is a combination of the reproducer posted here: rust-lang#128887 (comment) and the existing test for polymorphic recursion: https://github.com/rust-lang/rust/blob/784d444733d65c3d305ce5edcbb41e3d0d0aee2e/tests/mir-opt/inline/polymorphic_recursion.rs

r? ``@compiler-errors``
Make the "detect-old-time" UI test more representative

The test code did have an inference failure, but that would have failed
on Rust 1.79 and earlier too. Now it is rewritten to be specifically
affected by 1.80's `impl FromIterator<_> for Box<str>`.
…g-4, r=jieyouxu

Remove `#[macro_use] extern crate tracing`, round 4

Because explicit importing of macros via use items is nicer (more standard and readable) than implicit importing via #[macro_use]. Continuing the work from rust-lang#124511, rust-lang#124914, and rust-lang#125434. After this PR no `rustc_*` crates use `#[macro_use] extern crate tracing` except for `rustc_codegen_gcc` which is a special case and I will do separately.

r? ``@jieyouxu``
…g-remainder, r=GuillaumeGomez

Remove `#[macro_use] extern crate tracing` from rustdoc and rustfmt

A follow-up to rust-lang#129767 and earlier PRs doing this for `rustc_*` crates.

r? ``@GuillaumeGomez``
mark joboet as on vacation

I'll be on vacation for about three weeks and won't have much time for reviewing.

r? ```@ghost```
@rustbot rustbot added A-meta Area: Issues about the rust-lang/rust repository. A-rustdoc-json Area: Rustdoc JSON backend A-testsuite Area: The testsuite used to check the correctness of rustc S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative rollup A PR which is a rollup labels Aug 31, 2024
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=11

@bors
Copy link
Contributor

bors commented Aug 31, 2024

📌 Commit f82ce17 has been approved by matthiaskrgr

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Aug 31, 2024
@bors
Copy link
Contributor

bors commented Aug 31, 2024

⌛ Testing commit f82ce17 with merge 98c77d7...

bors added a commit to rust-lang-ci/rust that referenced this pull request Aug 31, 2024
…iaskrgr

Rollup of 11 pull requests

Successful merges:

 - rust-lang#129630 (Document the broken C ABI of `wasm32-unknown-unknown`)
 - rust-lang#129711 (Expand NLL MIR dumps)
 - rust-lang#129730 (f32 docs: define 'arithmetic' operations)
 - rust-lang#129733 (Subtree update of `rust-analyzer`)
 - rust-lang#129749 (llvm-wrapper: adapt for LLVM API changes)
 - rust-lang#129757 (Add a test for trait solver overflow in MIR inliner cycle detection)
 - rust-lang#129760 (Make the "detect-old-time" UI test more representative)
 - rust-lang#129767 (Remove `#[macro_use] extern crate tracing`, round 4)
 - rust-lang#129774 (Remove `#[macro_use] extern crate tracing` from rustdoc and rustfmt)
 - rust-lang#129785 (Miri subtree update)
 - rust-lang#129791 (mark joboet as on vacation)

Failed merges:

 - rust-lang#129777 (Add `unreachable_pub`, round 4)

r? `@ghost`
`@rustbot` modify labels: rollup
@rust-log-analyzer
Copy link
Collaborator

The job x86_64-msvc failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

---- C:\a\rust\rust\src/doc/rustc\src\platform-support\wasm32-unknown-unknown.md - Tier__2::Broken_ (line 208) stdout ----
error: linking with `link.exe` failed: exit code: 1120
  |
  = note: "C:\\Program Files\\Microsoft Visual Studio\\2022\\Enterprise\\VC\\Tools\\MSVC\\14.41.34120\\bin\\HostX64\\x64\\link.exe" "/NOLOGO" "C:\\a\\_temp\\msys64\\tmp\\rustcKmpKdp\\symbols.o" "C:\\a\\_temp\\msys64\\tmp\\rustdoctesti4mVlp\\rust_out.rust_out.55b229272e406834-cgu.0.rcgu.o" "C:\\a\\_temp\\msys64\\tmp\\rustdoctesti4mVlp\\rust_out.7be3xp2wpsgglrtd3bm2a032v.rcgu.o" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd-65608d36b6ec3eee.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libpanic_unwind-084afa9dbb9f5613.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libwindows_targets-6bfa9ea28a1d6264.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\librustc_demangle-1ea7f79e6303cc43.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libstd_detect-752e6ff6f24ed0a5.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libhashbrown-bc433452086bd0c3.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\librustc_std_workspace_alloc-294f22927bbd47f9.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libunwind-8bcc5244e2d1a33a.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcfg_if-c575f888152b6d91.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\liballoc-95df9ce7fa76d5b4.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\librustc_std_workspace_core-ae2fade04ec27265.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcore-d373f053f076a95d.rlib" "C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\x86_64-pc-windows-msvc\\lib\\libcompiler_builtins-81442eca42d68b43.rlib" "kernel32.lib" "kernel32.lib" "advapi32.lib" "ntdll.lib" "userenv.lib" "ws2_32.lib" "/defaultlib:msvcrt" "/NXCOMPAT" "/OUT:C:\\a\\_temp\\msys64\\tmp\\rustdoctesti4mVlp\\rust_out.exe" "/OPT:REF,NOICF" "/DEBUG" "/PDBALTPATH:%_PDB%" "/NATVIS:C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\etc\\intrinsic.natvis" "/NATVIS:C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\etc\\liballoc.natvis" "/NATVIS:C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\etc\\libcore.natvis" "/NATVIS:C:\\a\\rust\\rust\\build\\x86_64-pc-windows-msvc\\stage2\\lib\\rustlib\\etc\\libstd.natvis"
  = note: rust_out.rust_out.55b229272e406834-cgu.0.rcgu.o : error LNK2019: unresolved external symbol take_my_pair referenced in function call_c␍
          C:\a\_temp\msys64\tmp\rustdoctesti4mVlp\rust_out.exe : fatal error LNK1120: 1 unresolved externals␍

error: aborting due to 1 previous error

Couldn't compile the test.
Couldn't compile the test.

failures:
    C:\a\rust\rust\src/doc/rustc\src\platform-support\wasm32-unknown-unknown.md - Tier__2::Broken_ (line 208)

test result: FAILED. 0 passed; 1 failed; 2 ignored; 0 measured; 0 filtered out; finished in 0.11s

Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 1:22:55
make: *** [Makefile:102: ci-msvc-ps1] Error 1
  network time: Sat, 31 Aug 2024 12:43:24 GMT
##[error]Process completed with exit code 2.
Post job cleanup.
[command]"C:\Program Files\Git\bin\git.exe" version

@bors
Copy link
Contributor

bors commented Aug 31, 2024

💔 Test failed - checks-actions

@bors bors added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Aug 31, 2024
@matthiaskrgr matthiaskrgr deleted the rollup-ftlptye branch September 1, 2024 17:35
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-meta Area: Issues about the rust-lang/rust repository. A-rustdoc-json Area: Rustdoc JSON backend A-testsuite Area: The testsuite used to check the correctness of rustc rollup A PR which is a rollup S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-bootstrap Relevant to the bootstrap subteam: Rust's build system (x.py and src/bootstrap) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative
Projects
None yet
Development

Successfully merging this pull request may close these issues.