Improve rustdoc-gui search-color test
Thanks to the add of "functions" in `browser-ui-test`, we can start to reduce the size of the scripts. It'll be very useful for all color checks.
r? `@notriddle`
suggest candidates for unresolved import
Currently we prompt suggestion of candidates(help notes of `use xxx::yyy`) for names which cannot be resolved, but we don't do that for import statements themselves that couldn't be resolved. It seems reasonable to add candidate help information for these statements as well.
Fixes#102711
rustdoc: clean up overly complex `.trait-impl` CSS selectors
When added in 45964368f4a2e31c94e9bcf1cef933c087d21544, these multi-class selectors were present in the initial commit, but no reason was given why the shorter selector wouldn't work.
update to syn-1.0.102
This update removes the only `.gitignore` found in `rustc-src`:
vendor/syn/tests/.gitignore
vendor/syn-1.0.91/tests/.gitignore
vendor/syn-1.0.95/tests/.gitignore
To check-in `rustc-src` for hermetic builds in environments with
restrictive `.gitignore` policies, one has to remove these
`tests/.gitignore` and patch the respective
`.cargo-checksum.json`.`syn` >1.0.101 includes dtolnay/syn@3c49303bed,
which removes its `tests/.gitignore`. Now the `syn` crates.io package
has no `.gitignore`.
[`rustc-src`'s `vendor`][] is produced from the root `Cargo.toml`,
`src/tools/rust-analyzer/Cargo.toml`,
`compiler/rustc_codegen_cranelift/Cargo.toml`, and
`src/bootstrap/Cargo.toml`. `rustc_codegen_cranelift` does not use
`syn`.
[`rustc-src`'s `vendor`]:
https://github.com/rust-lang/rust/blob/c0784109daa0/src/bootstrap/dist.rs#L934-L940
This was produced with:
cargo update --package syn --precise 1.0.102 \
cargo update --package syn --precise 1.0.102 \
--manifest-path src/tools/rust-analyzer/Cargo.toml
cargo update --package syn --precise 1.0.102 \
--manifest-path src/bootstrap/Cargo.toml
Update manual now stable can be installed with rustup
this a new PR for #13374 as `bors squash` seemed to have broken `bors`
_______
`rustup` can now install `rust-analyzer` for the stable tool-chain. This commit removes the note that `rustup` can only install for the nightly branch and adjusts the command.
I also added a note on how to find the path to the `rust-analyzer` binary when installed using `rustup`, and suggestions on how to work around it not being placed in `~/.cargo/bin`.
I thought it would be ideal to point everyone to use `rustup run stable rust-analyzer` to start `rust-analyzer`. That would make it trivial to switch to nightly however I could not get this to work in `nvim` therefore I left it as a suggestion at the end.
`rustup` can now install `rust-analyzer` for the stable tool-chain. This commit removes the note that `rustup` can only install for the nightly branch and adjusts the command.
I also added a note on how to find the path to the `rust-analyzer` binary when installed using `rustup`, and suggestions on how to work around it not being placed in `~/.cargo/bin`.
I thought it would be ideal to point everyone to use `rustup run stable rust-analyzer` to start `rust-analyzer`. That would make it trivial to switch to nightly however I could not get this to work in `nvim` therefore I left it as a suggestion at the end.
Refactor completions expansion
Depends on https://github.com/rust-lang/rust-analyzer/pull/13384
Diff is unfortunately massive as I changed the functions in the analysis module from associated ones to standalone (unfortunately without an extra commit)
Don't report build-scripts and proc-macros as metadata progress
Seems somewhat confusing to me, given `metadata` is already the step we do for workspace loading
Expand unmatched mbe fragments to reasonable default token trees
Currently we expand unmatched fragments by not replacing them at all, leaving us with `$ident`. This trips up the parser or subsequent macro calls. Instead it makes more sense to replace these with some reasonable default depending on the fragment kind which should make more recursive macro calls work better for completions.
Currently we expand unmatched fragments by not replacing them at all,
leaving us with `$ident`. This trips up the parser or subsequent macro
calls. Instead it makes more sense to replace these with some reasonable
default depending on the fragment kind which should make more recursive
macro calls work better for completions.
Add convert_named_struct_to_tuple_struct assist
Closes#11643, since the assist for converting in the other direction is already there (I based most of the implementation and all of the tests on it).
fix: in VSCode, correctly resolve relative paths to errors
VS Code problem matcher are restricted to be static "regexes". You can't create a problem matcher dynamically, and you can't use custom code in lieu of problem matcher.
This creates a problem for rust/cargo compiler errors. They use paths relative to the root of the Cargo workspace, but VS Code doesn't necessary know where that root is.
Luckily, there's a way out: our current problem matcher is defined like this:
"fileLocation": [ "autoDetect", "${workspaceRoot}" ],
That means that relative pahts would be resoleved relative to workspace root. VS Code allows to specify a command inside `${}`. So we can plug custom logic there to fetch Cargo's workspace root!
And that's exactly what this PR is doing!
internal: Add `GenericParamList::to_generic_args` and `{TypeParam,ConstParam}::remove_default` APIs
Also fixes `generate_impl` not removing the default const param value, though it seems that no one has encountered or reported that issue yet 😅
This initially started out as refactoring `utils::generate_impl_text_inner` to understand it better (which was the reason for adding `{TypeParam,ConstParam}::remove_default`), but ended up also finding another place that needed `GenericParamList::to_generic_args`, hence its addition in here.
Use BOLT in CI to optimize LLVM
This PR adds an optimization step in the Linux `dist` CI pipeline that uses [BOLT](https://github.com/llvm/llvm-project/tree/main/bolt) to optimize the `libLLVM.so` library built by boostrap.
Steps:
- [x] Use LLVM 15 as a bootstrap compiler and use it to build BOLT
- [x] Compile LLVM with support for relocations (`-DCMAKE_SHARED_LINKER_FLAGS="-Wl,-q"`)
- [x] Gather profile data using instrumented LLVM
- [x] Apply profile to LLVM that has already been PGOfied
- [x] Run with BOLT profiling on more benchmarks
- [x] Decide on the order of optimization (PGO -> BOLT?)
- [x] Decide how we should get `bolt` (currently we use the host `bolt`)
- [x] Clean up
The latest perf results can be found [here](https://github.com/rust-lang/rust/pull/94381#issuecomment-1258269440). The current CI build time with BOLT applied is around 1h 55 minutes.
add Vec::push_within_capacity - fallible, does not allocate
This method can serve several purposes. It
* is fallible
* guarantees that items in Vec aren't moved
* allows loops that do `reserve` and `push` separately to avoid pulling in the allocation machinery a second time in the `push` part which should make things easier on the optimizer
* eases the path towards `ArrayVec` a bit since - compared to `push()` - there are fewer questions around how it should be implemented
I haven't named it `try_push` because that should probably occupy a middle ground that will still try to reserve and only return an error in the unlikely OOM case.
resolves#84649
VS Code problem matcher are restricted to be static "regexes". You can't
create a problem matcher dynamically, and you can't use custom code in
lieu of problem matcher.
This creates a problem for rust/cargo compiler errors. They use paths
relative to the root of the Cargo workspace, but VS Code doesn't
necessary know where that root is.
Luckily, there's a way out: our current problem matcher is defined like
this:
"fileLocation": [ "autoDetect", "${workspaceRoot}" ],
That means that relative pahts would be resoleved relative to workspace
root. VS Code allows to specify a command inside `${}`. So we can plug
custom logic there to fetch Cargo's workspace root!
And that's exactly what this PR is doing!
internal: ⬆️ xflags
The main change here should be that flags are not inhereted, so
$ rust-analyzer analysis-stats . -v -v
would do what it should do
We also no longer Don\'t
The main change here should be that flags are not inhereted, so
$ rust-analyzer analysis-stats . -v -v
would do what it should do
We also no longer Don\'t
std: use futex in `Once`
Now that we have efficient locks, let's optimize the rest of `sync` as well. This PR adds a futex-based implementation for `Once`, which drastically simplifies the implementation compared to the generic version, which is provided as fallback for platforms without futex (Windows only supports them on newer versions, so it uses the fallback for now).
Instead of storing a linked list of waiters, the new implementation adds another state (`QUEUED`), which is set when there are waiting threads. These now use `futex_wait` on that state and are woken by the running thread when it finishes and notices the `QUEUED` state, thereby avoiding unnecessary calls to `futex_wake_all`.
fix: Make go-to-def work for `#[doc = include_str!("path")]`
See the added test, go-to-def on `#[doc = include_str!("path$0")]` should navigate to `path`.
