Over in Zed we've noticed that loading crates for a large-ish workspace can take almost 200ms. We've pinned it down to how rustc searches for paths, as it performs a linear search over the list of candidate paths. In our case the candidate list had about 20k entries which we had to iterate over for each dependency being loaded.
This commit introduces a simple FilesIndex that's just a sorted Vec under the hood. Since crates are looked up by both prefix and suffix, we perform a range search on said Vec (which constraints the search space based on prefix) and follow up with a linear scan of entries with matching suffixes.
FilesIndex is also pre-filtered before any queries are performed using available target information; query prefixes/sufixes are based on the target we are compiling for, so we can remove entries that can never match up front.
Overall, this commit brings down build time for us in dev scenarios by about 6%.
100ms might not seem like much, but this is a constant cost that each of our workspace crates has to pay, even when said crate is miniscule.
Rollup of 8 pull requests
Successful merges:
- #132790 (Add as_slice/into_slice for IoSlice/IoSliceMut.)
- #132905 ([AIX] Add crate "unwind" to link with libunwind)
- #132977 (Fix compilation error on Solaris due to flock usage)
- #132984 ([illumos] use pipe2 to create anonymous pipes)
- #133019 (docs: Fix missing period and colon in methods for primitive types)
- #133048 (use `&raw` in `{read, write}_unaligned` documentation)
- #133050 (Always inline functions signatures containing `f16` or `f128`)
- #133053 (tests: Fix the SIMD FFI tests with certain x86 configuration)
r? `@ghost`
`@rustbot` modify labels: rollup
tests: Fix the SIMD FFI tests with certain x86 configuration
This pull request fixes the SIMD FFI tests with certain x86 configurations by gating the SSE2 intrinsic behind the `sse2` feature gate. A generic LLVM intrinsic that is easy to un-fuse on those platforms is added to compensate for those platforms.
Always inline functions signatures containing `f16` or `f128`
There are a handful of tier 2 and tier 3 targets that cause a LLVM crash or linker error when generating code that contains `f16` or `f128`. The cranelift backend also does not support these types. To work around this, every function in `std` or `core` that contains these types must be marked `#[inline]` in order to avoid sending any code to the backend unless specifically requested.
However, this is inconvenient and easy to forget. Introduce a check for these types in the frontend that automatically inlines any function signatures that take or return `f16` or `f128`.
Note that this is not a perfect fix because it does not account for the types being passed by reference or as members of aggregate types, but this is sufficient for what is currently needed in the standard library.
Fixes: https://github.com/rust-lang/rust/issues/133035
Closes: https://github.com/rust-lang/rust/pull/133037
Fix compilation error on Solaris due to flock usage
PR 130999 added the file_lock feature, but libc does not define flock() for the Solaris platform leading to a compilation error.
Additionally, I went through all the Tier 2 platforms and read through their documentation to see whether flock was implemented. This turned up 5 more Unix platforms where flock is not supported, even though it may exist in the libc crate.
Fixes https://github.com/rust-lang/rust/issues/132921
Related to #130999
[AIX] Add crate "unwind" to link with libunwind
The Rust on IBM AIX uses LLVM's `libunwind`. Since crate `unwind` is a dependency of crate `std` and `#![no_std]` is specified in the test case, `libunwind` is not included in the link command by default. As a result, the test case fails to link with the error "Undefined symbol: ._Unwind_Resume" on AIX. This PR explicitly adds crate `unwind` for AIX, along with feature `panic_unwind`, which is required to include the `unwind` crate.
There are a handful of tier 2 and tier 3 targets that cause a LLVM crash
or linker error when generating code that contains `f16` or `f128`. The
cranelift backend also does not support these types. To work around
this, every function in `std` or `core` that contains these types must
be marked `#[inline]` in order to avoid sending any code to the backend
unless specifically requested.
However, this is inconvenient and easy to forget. Introduce a check for
these types in the frontend that automatically inlines any function
signatures that take or return `f16` or `f128`.
Note that this is not a perfect fix because it does not account for the
types being passed by reference or as members of aggregate types, but
this is sufficient for what is currently needed in the standard library.
Fixes: https://github.com/rust-lang/rust/issues/133035
Closes: https://github.com/rust-lang/rust/pull/133037
These types are currently passed by reference, which does not avoid the
backend crashes. Change these back to being passed by value, which makes
the types easier to detect for automatic inlining.
[rustdoc] Fix handling of footnote reference in footnote definition
Fixes https://github.com/rust-lang/rust/issues/131946.
We didn't check if we had footnote reference in footnote definition.
r? `@notriddle`
Skip locking span interner for some syntax context checks
- `from_expansion` now never needs to consult the interner
- `eq_ctxt` now only needs the interner when both spans are fully interned
borrowck diagnostics: suggest borrowing function inputs in generic positions
# Summary
This generalizes borrowck's existing suggestions to borrow instead of moving when passing by-value to a function that's generic in that input. Previously, this was special-cased to `AsRef`/`Borrow`-like traits and `Fn`-like traits. This PR changes it to test if, for a moved place with type `T`, that the callee's signature and clauses don't break if you substitute in `&T` or `&mut T`. For instance, it now works with `Read`/`Write`-like traits.
Fixes https://github.com/rust-lang/rust/issues/131413
# Incidental changes
- No longer spuriously suggests mutable borrows of closures in some situations (see e.g. the tests in [tests/ui/closures/2229_closure_analysis/](https://github.com/rust-lang/rust/compare/master...dianne:rust:suggest-borrow-generic?expand=1#diff-8dfb200c559f0995d0f2ffa2f23bc6f8041b263e264e5c329a1f4171769787c0)).
- No longer suggests cloning closures that implement `Fn`, since they can be borrowed (see e.g. [tests/ui/moves/borrow-closures-instead-of-move.stderr](https://github.com/rust-lang/rust/compare/master...dianne:rust:suggest-borrow-generic?expand=1#diff-5db268aac405eec56d099a72d8b58ac46dab523cf013e29008104840168577fb)).
This keeps the behavior to suppress suggestions of `fn_once.clone()()`. I think it might make sense to suggest it with a "but this might not be your desired behavior" caveat, as is done when something is used after being consumed as the receiver for a method call. That's probably out of the scope of this PR though.
# Limitations and possible improvements
- This doesn't work for receivers of method calls. This is a small change, and I have it implemented locally, but I'm not sure it's useful on its own. In most cases I've found borrowing the receiver would change the call's output type (see below). In other cases (e.g. `Iterator::sum`), borrowing the receiver isn't useful since it's consumed.
- This doesn't work when it would change the call's output type. In general, I figure inserting references into the output type is an unwanted change. However, this also means it doesn't work in cases where the new output type would be effectively the same as the old one. For example, from the rand crate, the iterator returned by [`Rng::sample_iter`](https://docs.rs/rand/latest/rand/trait.Rng.html#method.sample_iter) is effectively the same (modulo regions) whether you borrow or consume the receiver `Rng`, so common usage involves borrowing it. I'm not sure whether the best approach is to add a more complex check of approximate equivalence, to forego checking the call's output type and give spurious suggestions, or to leave it as-is.
- This doesn't work when it would change the call's other input types. Instead, it could suggest borrowing any others that have the same parameter type (but only when suggesting shared borrows). I think this would be a pretty easy change, but I don't think it's very useful so long as the normalized output type can't change.
I'm happy to implement any of these (or other potential improvements to this), but I'm not sure which are common enough patterns to justify the added complexity. Please let me know if any sound worthwhile.
Rollup of 5 pull requests
Successful merges:
- #132010 (ci: Enable full `debuginfo-level=2` in `DEPLOY_ALT`)
- #132310 (compiletest: add `max-llvm-major-version` directive)
- #132773 (PassWrapper: disable UseOdrIndicator for Asan Win32)
- #133013 (compiletest: known-bug / crashes: allow for an "auxiliary" directory to contain files that do not have a "known-bug" directive)
- #133027 (Fix a copy-paste issue in the NuttX raw type definition)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix a copy-paste issue in the NuttX raw type definition
This file is copied from the rtems as initial implementation, and forgot to change the OS name in the comment.
compiletest: known-bug / crashes: allow for an "auxiliary" directory to contain files that do not have a "known-bug" directive
Fixes#133009
r? `@jieyouxu`
PassWrapper: disable UseOdrIndicator for Asan Win32
As described in https://reviews.llvm.org/D137227 UseOdrIndicator should be disabled on Windows since link.exe does not support duplicate weak definitions.
Fixes https://github.com/rust-lang/rust/issues/124390.
Credits also belong to `@1c3t3a` who worked with me on this.
We are currently testing this on a Windows machine.
compiletest: add `max-llvm-major-version` directive
To complement existing `min-llvm-version` so contributors don't have to use `ignore-llvm-version: 20 - 99` to emulate `max-llvm-major-version: 19`.
Closes#132305.
cc `@workingjubilee` who suggested this.
### Implementation steps
- [x] 1. Implement the directive (this PR)
- [x] 2. Open an accompanying dev-guide PR to describe the directive (https://github.com/rust-lang/rustc-dev-guide/pull/2129)
r? bootstrap
ci: Enable full `debuginfo-level=2` in `DEPLOY_ALT`
It will be slower to build and produce larger artifacts, but hopefully
it will help catch debuginfo regressions sooner, especially for problems
that LLVM assertions would uncover.
try-job: dist-x86_64-linux
try-job: dist-x86_64-linux-alt
Rollup of 7 pull requests
Successful merges:
- #131304 (float types: move copysign, abs, signum to libcore)
- #132907 (Change intrinsic declarations to new style)
- #132971 (Handle infer vars in anon consts on stable)
- #133003 (Make `CloneToUninit` dyn-compatible)
- #133004 (btree: simplify the backdoor between set and map)
- #133008 (update outdated comment about test-float-parse)
- #133012 (Add test cases for #125918)
r? `@ghost`
`@rustbot` modify labels: rollup
This file is copied from the rtems as initial implementation, and
forgot to change the OS name in the comment.
Signed-off-by: Huang Qi <huangqi3@xiaomi.com>
Piotr Osiewicz