1
Fork 0
Commit graph

264910 commits

Author SHA1 Message Date
Guillaume Gomez
e5cd26a22e
Rollup merge of #129243 - onur-ozkan:stuff, r=Kobzol
do not build `cargo-miri` by default on stable channel

Skips `cargo-miri` build on `stable` channel just like `miri`.

Closes #129171

cc ``@RalfJung``
2024-08-23 12:32:14 +02:00
Guillaume Gomez
440076db48
Rollup merge of #128511 - alexcrichton:doc-wasm-features, r=jieyouxu
Document WebAssembly target feature expectations

This commit is a result of the discussion on #128475 and incorporates parts of #109807 as well. This is all done as a new page of documentation for the `wasm32-unknown-unknown` target which previously did not exist. This new page goes into details about the preexisting target and additionally documents the expectations for WebAssembly features and code generation.

The tl;dr is that LLVM will enable features over time after most engines have had support for awhile. Compiling without features requires `-Ctarget-cpu=mvp` to rustc plus `-Zbuild-std` to Cargo.

Closes #109807
Closes #119811
Closes #128475
2024-08-23 12:32:14 +02:00
bors
3a097e1659 Auto merge of #17857 - ChayimFriedman2:rust-project-cfg-group, r=Veykril
feat: Allow declaring cfg groups in rust-project.json, to help sharing common cfgs

Closes #17815.
2024-08-23 10:01:35 +00:00
bors
e030cf01ba Auto merge of #17946 - Veykril:flycheck-crates-for, r=Veykril
internal: Don't requery crates_for for flycheck when crates are known
2024-08-23 09:47:05 +00:00
Lukas Wirth
5f7489a3d7 internal: Don't requery crates_for for flycheck when crates are known 2024-08-23 11:45:47 +02:00
bors
ac912c7b22 Auto merge of #17936 - Veykril:module_path, r=Veykril
feat: Implement `module_path` macro

Turns out this is a pain to implement because of our hir-def hir-expand split :)
2024-08-23 09:32:27 +00:00
bors
39cc5b61f8 Auto merge of #17927 - ChayimFriedman2:speedup-new-usages, r=Veykril
perf: Speed up search for short associated functions, especially very common identifiers such as `new`

`@Veykril` said in https://github.com/rust-lang/rust-analyzer/pull/17908#issuecomment-2292958068 that people complain searches for `new()` are slow (they are right), so here I am to help!

The search is used by IDE features such as rename and find all references.

The search is slow because we need to verify each candidate, and that requires analyzing it; the key to speeding it up is to avoid the analysis where possible.

I did that with a bunch of tricks that exploits knowledge about the language and its possibilities. The first key insight is that associated methods may only be referenced in the form `ContainerName::func_name` (parentheses are not necessary!) (Rust doesn't include a way to `use Container::func_name`, and even if it will in the future most usages are likely to stay in that form.

Searching for `::` will help only a bit, but searching for `Container` can help considerably, since it is very rare that there will be two identical instances of both a container and a method of it.

However, things are not as simple as they sound. In Rust a container can be aliased in multiple ways, and even aliased from different files/modules. If we will try to resolve the alias, we will lose any gain from the textual search (although very common method names such as `new` will still benefit, most will suffer because there are more instances of a container name than its associated item).

This is where the key trick enters the picture. The key insight is that there is still a textual property: a container namer cannot be aliased, unless its name is mentioned in the alias declaration, or a name of alias of it is mentioned in the alias declaration.

This becomes a fixpoint algorithm: we expand our list of aliases as we collect more and more (possible) aliases, until we eventually reach a fixpoint. A fixpoint is not guaranteed (and we do have guards for the rare cases where it does not happen), but it is almost so: most types have very few aliases, if at all.

We do use some semantic information while analyzing aliases. It's a balance: too much semantic analysis, and the search will become slow. But too few of it, and we will bring many incorrect aliases to our list, and risk it expands and expands and never reach a fixpoint. At the end, based on benchmarks, it seems worth to do a lot to avoid adding an alias (but not too much), while it is worth to do a lot to avoid the need to semantically analyze func_name matches (but again, not too much).

After we collected our list of aliases, we filter matches based on this list. Only if a match can be real, we do semantic analysis for it.

The results are promising: searching for all references on `new()` in `base-db` in the rust-analyzer repository, which previously took around 60 seconds, now takes as least as two seconds and a half (roughly), while searching for `Vec::new()`, almost an upper bound to how much a symbol can be used, that used to take 7-9 minutes(!) now completes in 100-120 seconds, and with less than half of non-verified results (aka. false positives).

This is the less strictly correct (but faster) branch of this patch; it can miss some (rare) cases (there is a test for that - `goto_ref_on_short_associated_function_complicated_type_magic_can_confuse_our_logic()`). There is another branch that have no false negatives but is slower to search (`Vec::new()` never reaches a fixpoint in aliases collection there). I believe it is possible to create a strategy that will have the best of both worlds, but it will involve significant complexity and I didn't bother, especially considering that in the vast majority of the searches the other branch will be more than enough. But all in all, I decided to bring this branch (of course if the maintainers will agree), since our search is already not 100% accurate (it misses macros), and I believe there is value in the additional perf.

You can find the strict branch at https://github.com/ChayimFriedman2/rust-analyzer/tree/speedup-new-usages-strict.

Should fix #7404, I guess (will check now).
2024-08-23 09:17:47 +00:00
Lukas Wirth
916c559890
Remove incorrect FIXME comment 2024-08-23 11:05:25 +02:00
bors
b88a4f01da Auto merge of #17912 - alibektas:cargo_check_on_binary, r=Veykril
fix: run flycheck without rev_deps when target is specified

Since querying for a crate's target is a call to salsa and therefore blocking, flycheck task is now deferred out of main thread by using `GlobalState`s `deferred_task_queue`. Fixes #17829  and https://github.com/rust-lang/rustlings/issues/2071
2024-08-23 09:03:11 +00:00
bors
c8b14ba7b6 Auto merge of #129443 - matthiaskrgr:rollup-tbgdj0p, r=matthiaskrgr
Rollup of 8 pull requests

Successful merges:

 - #127623 (fix: fs::remove_dir_all: treat internal ENOENT as success)
 - #128876 (Ship MinGW-w64 runtime DLLs along with `rust-lld.exe` for `-pc-windows-gnu` targets)
 - #129055 (Migrate `x86_64-fortanix-unknown-sgx-lvi` `run-make` test to rmake)
 - #129386 (Use a LocalDefId in ResolvedArg.)
 - #129400 (Update `compiler_builtins` to `0.1.120`)
 - #129414 (Fix extern crates not being hidden with `doc(hidden)`)
 - #129417 (Don't trigger refinement lint if predicates reference errors)
 - #129433 (Fix a missing import in a doc in run-make-support)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-08-23 08:31:26 +00:00
Jakub Beránek
2339560239
kobzol vacation 2024-08-23 10:20:24 +02:00
Matthias Krüger
6c2ee6fe77
Rollup merge of #129433 - GrigorenkoPV:run-make-support-path-rustdoc, r=jieyouxu
Fix a missing import in a doc in run-make-support
2024-08-23 06:26:55 +02:00
Matthias Krüger
32821b9f8a
Rollup merge of #129417 - compiler-errors:refine-err, r=lqd
Don't trigger refinement lint if predicates reference errors

Fixes #129404
2024-08-23 06:26:54 +02:00
Matthias Krüger
65af38a0d2
Rollup merge of #129414 - GuillaumeGomez:fix-doc-hidden-crates, r=notriddle
Fix extern crates not being hidden with `doc(hidden)`

Fixes #126796.

Only the current crate should never be stripped, any other crate should be strippable.

r? ``@notriddle``
2024-08-23 06:26:54 +02:00
Matthias Krüger
79d36669b5
Rollup merge of #129400 - Amjad50:update-compiler-builtins, r=tgross35
Update `compiler_builtins` to `0.1.120`

Includes https://github.com/rust-lang/compiler-builtins/pull/672 which fixes regression issue with Apple and Windows compilers.

try-job: aarch64-apple
try-job: x86_64-apple-1
try-job: x86_64-msvc
2024-08-23 06:26:53 +02:00
Matthias Krüger
487b3d92cf
Rollup merge of #129386 - cjgillot:local-resolved-arg, r=compiler-errors
Use a LocalDefId in ResolvedArg.
2024-08-23 06:26:53 +02:00
Matthias Krüger
fe87433e8a
Rollup merge of #129055 - Oneirical:fortanix-fortification, r=jieyouxu
Migrate `x86_64-fortanix-unknown-sgx-lvi` `run-make` test to rmake

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

The final Makefile! Every Makefile test is now claimed.

This is difficult to test due to the uncommon architecture it is specific to. I don't think it is in the CI (I didn't find it in `jobs.yml`, but if there is a way to test it, please do.

Locally, on Linux, it compiles and panics at the `llvm_filecheck` part (if I replace the `x86_64-fortanix-unknown-sgx` with `x86_64-unknown-linux-gnu`, of course), which is expected.

For this reason, the Makefile and associated script have been kept, but with a leading underscore.
2024-08-23 06:26:52 +02:00
Matthias Krüger
6a1418aafe
Rollup merge of #128876 - ColinFinck:rust-lld-with-runtime-dlls, r=Kobzol,petrochenkov,jieyouxu
Ship MinGW-w64 runtime DLLs along with `rust-lld.exe` for `-pc-windows-gnu` targets

`rust-lld.exe` built for `x86_64-pc-windows-gnu` depends on `libgcc_s_seh-1.dll` and `libwinpthread-1.dll` from MinGW-w64. Until now, they were not shipped alongside `rust-lld.exe`, and you could not run `rust-lld.exe` on most systems.

This problem didn't surface until now because:
* Most targets don't use `rust-lld` by default.
* Some people had these DLLs in their `PATH` from some other MinGW binary.
* `rustup` used to add `bin` to the `PATH`, which contains these DLLs for `rustc.exe`. But it no longer does that: ce3c09a0cb

Fixes #125809

try-job: dist-x86_64-mingw
2024-08-23 06:26:52 +02:00
Matthias Krüger
370b3265ff
Rollup merge of #127623 - lolbinarycat:fix_remove_dir_all, r=Amanieu
fix: fs::remove_dir_all: treat internal ENOENT as success

fixes #127576

try-job: test-various
2024-08-23 06:26:51 +02:00
Gurinder Singh
b544603c03 Fix typo in help diagnostic 2024-08-23 08:21:25 +05:30
Zalathar
585804fcee Check that library/profiler_builtins actually found some source files
The current `build.rs` will automatically skip source files that don't exist.
An unfortunate side-effect is that if _no_ files could be found (e.g. because
the directory was wrong), the build fails with a mysterious linker error.

We can reduce the awkwardness of this by explicitly checking that at least one
source file was found.
2024-08-23 10:10:34 +10:00
Pavel Grigorenko
9ad0b15a8e Fix a missing import in a doc in run-make-support 2024-08-23 02:44:15 +03:00
binarycat
d1b41f3747 remove dbg!() 2024-08-22 19:04:34 -04:00
bors
b5723af345 Auto merge of #129413 - jieyouxu:revert-remove-dir-all, r=compiler-errors
Revert #129187 and #129302

The two PRs naively switched to `std::fs::remove_dir_all`, but failed to gracefully handle the failure case where the top-level directory entry does not exist, causing https://github.com/rust-lang/rust/pull/129187#issuecomment-2304849757 `./x clean` to fail locally when `tmp` does not exist.

I plan to reland the two PRs with fixed top-level dir entry handling and more testing, but let's quickly revert to unblock people.

Reverts #129187.
Reverts #129302.

r? bootstrap
2024-08-22 22:51:03 +00:00
Ali Bektas
0251cfa33b Apply changes 2024-08-22 23:59:01 +02:00
Michael Howell
8151de2820 rustdoc-search: use tighter json for names and parents
File size
---------

```console
$ du -hs doc.old/search-index1.82.0.js doc/search-index1.82.0.js
3.2M    doc.old/search-index1.82.0.js
2.8M    doc/search-index1.82.0.js
$ gzip doc/search-index1.82.0.js
$ gzip doc.old/search-index1.82.0.js
$ du -hs doc.old/search-index1.82.0.js.gz doc/search-index1.82.0.js.gz
464K    doc.old/search-index1.82.0.js.gz
456K    doc/search-index1.82.0.js.gz
$ du -hs compiler-doc.old/search-index.js compiler-doc/search-index.js
8.5M    compiler-doc.old/search-index.js
6.5M    compiler-doc/search-index.js
$ gzip compiler-doc/search-index1.82.0.js
$ gzip compiler-doc.old/search-index1.82.0.js
$ du -hs compiler-doc.old/search-index.js.gz compiler-doc/search-index.js.gz
1.4M    compiler-doc.old/search-index.js.gz
1.4M    compiler-doc/search-index.js.gz
```
2024-08-22 14:33:25 -07:00
bors
eff09483c6 Auto merge of #129410 - RalfJung:miri-sync, r=RalfJung
Miri subtree update

r? `@ghost`
2024-08-22 20:25:09 +00:00
Guillaume Gomez
4de29c9047 Add regression test for #126796 2024-08-22 20:27:57 +02:00
Guillaume Gomez
e37e15dc0b Fix extern crates not being hidden with doc(hidden) 2024-08-22 20:27:57 +02:00
binarycat
988bc1c654 fix typos in new pointer conversion docs 2024-08-22 14:25:54 -04:00
binarycat
736f773844 fix: fs::remove_dir_all: treat ENOENT as success
fixes #127576

windows implementation still needs some work
2024-08-22 14:18:42 -04:00
Chayim Refael Friedman
a44152af15 Add cov_marks to test #17927 2024-08-22 20:52:51 +03:00
Chayim Refael Friedman
a57def2b39 Speed up search for short associated functions, especially very common identifiers such as new
The search is used by IDE features such as rename and find all references.

The search is slow because we need to verify each candidate, and that requires analyzing it; the key to speeding it up is to avoid the analysis where possible.

I did that with a bunch of tricks that exploits knowledge about the language and its possibilities. The first key insight is that associated methods may only be referenced in the form `ContainerName::func_name` (parentheses are not necessary!) (Rust doesn't include a way to `use Container::func_name`, and even if it will in the future most usages are likely to stay in that form.

Searching for `::` will help only a bit, but searching for `Container` can help considerably, since it is very rare that there will be two identical instances of both a container and a method of it.

However, things are not as simple as they sound. In Rust a container can be aliased in multiple ways, and even aliased from different files/modules. If we will try to resolve the alias, we will lose any gain from the textual search (although very common method names such as `new` will still benefit, most will suffer because there are more instances of a container name than its associated item).

This is where the key trick enters the picture. The key insight is that there is still a textual property: a container namer cannot be aliased, unless its name is mentioned in the alias declaration, or a name of alias of it is mentioned in the alias declaration.

This becomes a fixpoint algorithm: we expand our list of aliases as we collect more and more (possible) aliases, until we eventually reach a fixpoint. A fixpoint is not guaranteed (and we do have guards for the rare cases where it does not happen), but it is almost so: most types have very few aliases, if at all.

We do use some semantic information while analyzing aliases. It's a balance: too much semantic analysis, and the search will become slow. But too few of it, and we will bring many incorrect aliases to our list, and risk it expands and expands and never reach a fixpoint. At the end, based on benchmarks, it seems worth to do a lot to avoid adding an alias (but not too much), while it is worth to do a lot to avoid the need to semantically analyze func_name matches (but again, not too much).

After we collected our list of aliases, we filter matches based on this list. Only if a match can be real, we do semantic analysis for it.

The results are promising: searching for all references on `new()` in `base-db` in the rust-analyzer repository, which previously took around 60 seconds, now takes as least as two seconds and a half (roughly), while searching for `Vec::new()`, almost an upper bound to how much a symbol can be used, that used to take 7-9 minutes(!) now completes in 100-120 seconds, and with less than half of non-verified results (aka. false positives).

This is the less strictly correct (but faster) of this patch; it can miss some (rare) cases (there is a test for that - `goto_ref_on_short_associated_function_complicated_type_magic_can_confuse_our_logic()`). There is another branch that have no false negatives but is slower to search (`Vec::new()` never reaches a fixpoint in aliases collection there). I believe it is possible to create a strategy that will have the best of both worlds, but it will involve significant complexity and I didn't bother, especially considering that in the vast majority of the searches the other branch will be more than enough. But all in all, I decided to bring this branch (of course if the maintainers will agree), since our search is already not 100% accurate (it misses macros), and I believe there is value in the additional perf.
2024-08-22 20:52:51 +03:00
Chayim Refael Friedman
f65d60551b When descending into macros in search, first check if there is a need to - i.e. if we are inside a macro call
This avoids the need to analyze the file when we are not inside a macro call.

This is especially important for the optimization in the next commit(s), as there the common case will be to descent into macros but then not analyze.
2024-08-22 20:52:51 +03:00
Vadim Petrochenkov
f62b9e0179 rustc: Simplify getting sysroot library directory 2024-08-22 19:57:27 +03:00
bors
1b0e158df4 Auto merge of #17943 - Veykril:diags, r=Veykril
fix: Improve proc-macro panic message and workspace loading failure diagnostic
2024-08-22 16:47:56 +00:00
Lukas Wirth
0a277110b3 Improve proc-macro panic message and workspace loading failure diagnostic 2024-08-22 18:46:23 +02:00
Stephen Lazaro
e91f32829c Deduplicate Spans in Uninitialized Check
Prevents reporting labels or diagnostics on spans that are produced
multiple times.
2024-08-22 09:36:14 -07:00
Michael Goulet
8eb15586c6 Don't trigger refinement lint if predicates reference errors 2024-08-22 12:34:12 -04:00
bors
81a9956eb9 Auto merge of #17898 - Veykril:descend-2.0, r=Veykril
internal: Improve macro token mapping heuristics

Fixes https://github.com/rust-lang/rust-analyzer/issues/16235
2024-08-22 16:17:22 +00:00
Lukas Wirth
71c7ceaf52 Fix sorting order for tokens in hover 2024-08-22 18:08:36 +02:00
bors
06228b943b Auto merge of #17942 - HKalbasi:fp-const-eval, r=HKalbasi
Implement floating point casts in const eval

fix #17926
2024-08-22 16:02:50 +00:00
bors
b8c02eb11e Auto merge of #3835 - JoJoDeveloping:tb-fix-stack-overflow, r=RalfJung
Avoid extra copy by using `retain_mut` and moving the deletion into the closure

Fixes the FIXME introduced in #3833. Thanks to `@dmitrii-ubskii` for the idea 🙂
2024-08-22 15:55:11 +00:00
许杰友 Jieyou Xu (Joe)
3957f39339 Revert "compiletest: use std::fs::remove_dir_all now that it is available"
This reverts commit 75ed089727.
2024-08-22 15:55:06 +00:00
许杰友 Jieyou Xu (Joe)
e0900a1bb7 Revert "bootstrap: fix clean's remove_dir_all implementation"
This reverts commit 1687c55168.
2024-08-22 15:54:52 +00:00
bors
5ad98b4026 Auto merge of #129257 - ChrisDenton:rename-null-descriptor, r=jieyouxu
Allow rust staticlib to work with MSVC's /WHOLEARCHIVE

This fixes #129020 by renaming the `__NULL_IMPORT_DESCRIPTOR` to prevent conflicts.

try-job: dist-i686-msvc
2024-08-22 15:53:02 +00:00
Lukas Wirth
f9db48f8c9 Consider interleaving hover kinds 2024-08-22 17:29:32 +02:00
bors
e881c428f5 Auto merge of #3834 - sun-jacobi:tb-comment, r=RalfJung
Fix a misleading comment in `tests/pass/tree_borrows/tree-borrows.rs`

The original comment is somewhat misleading.

Since we don't add a protector for `x` here, `f` should be allowed to deallocate `x`.
2024-08-22 15:28:31 +00:00
Johannes Hostert
3a423fc6b7
Avoid extra copy by using retain_mut and moving the deletion into the closure 2024-08-22 17:18:11 +02:00
Lukas Wirth
b0e7ef4031 Sort hover results by relevance 2024-08-22 17:01:51 +02:00