Avoid ICE in borrowck
Provide a fallback in `best_blame_constraint` when `find_constraint_paths_between_regions` doesn't have a result. This code is due a rework to avoid the letf-over `unwrap()`, but avoids the ICE caused by the repro.
Fix#133252.
This makes this step take ~25ms on my machine (M3 Max 64GB) for Zed repo instead of ~150ms. Additionally it takes down the time needed for a clean cargo build of ripgrep from ~6.1s to 5.9s.
This change is mostly relevant for crates with multiple large CGUs.
compiletest: Slightly simplify the handling of debugger directive prefixes
The `cdbg-` prefix is not used by any tests in `tests/debuginfo`, and perhaps there never were any tests that used it.
Getting rid of it also lets us get rid of the code for parsing multiple prefixes at the same time, since every debugger now has exactly one prefix.
- librustdoc::clean::clean_lifetime doesn't need a mut doc context
- librustdoc::clean::normalize doesn't need a mut doc context
- move Some() wrapping up into `clean_predicate()`
- simplify nested if in librustdoc::clean::record_extern_fqn()
bootstrap: Allow `./x check compiletest`
Did you know that bootstrap didn't support `./x check compiletest`? Well, now it does!
Manually add `"compiletest"` to your `rust-analyzer.check.overrideCommand` check command to get error/warning integration when modifying compiletest.
bootstrap: drop warning for top-level test suite path check due to false positives
The current top-level test suite directory does not exist warning logic doesn't quite handle the more exotic path suffix matches that test filters seem to accept (e.g. `library/test` can be matched with `--exclude test`), so avoid warning on non-existent top-level test suites for now. To avoid false positives, we probably need to query test `Step`s for their `should_run(exclude_filter)` logic.
This retains the fix for the Windows path handling (unlike #134843).
r? `@onur-ozkan`
Unify fs::copy and io::copy on Linux
Currently, `fs::copy` first tries a regular file copy (via copy_file_range) and then falls back to userspace read/write copying. We should use `io::copy` instead as it tries copy_file_range, sendfile, and splice before falling back to userspace copying. This was discovered here: https://github.com/SUPERCILEX/fuc/issues/40
Perf impact: `fs::copy` will now have two additional statx calls to decide which syscall to use. I wonder if we should get rid of the statx calls and only continue down the next fallback when the relevant syscalls say the FD isn't supported.
This doesn't quite handle the more exotic path suffix matches that test
filters seem to accept (e.g. `library/test` can be matched with
`--exclude test`), so avoid warning on non-existent top-level test
suites for now. A proper fix will need to possibly query test `Step`s
for their exclude logic.
compiletest: Only pass the post-colon value to `parse_normalize_rule`
Addresses one of the FIXMEs noted in #134759.
I started working on the other FIXME, but it became complex enough that I wanted to split it off from this PR.
r? jieyouxu
Migrate `libs-through-symlink` to rmake.rs
Part of https://github.com/rust-lang/rust/issues/121876.
This PR migrates `tests/run-make/libs-through-symlink/` to use rmake.rs.
- Regression test for #13890.
- Original fix PR is #13903.
- Document test intent, backlink to #13890 and fix PR #13903.
- Fix the test logic: the `Makefile` version seems to not actually be exercising the "library search traverses symlink" logic, because the actual symlinked-to-library is present under the `$(TMPDIR)` directory tree when `bar.rs` is compiled, because the `$(RUSTC)` invocation has an implicit `-L $(TMPDIR)`. The symlink itself was actually broken, i.e. it should've been `ln -nsf $(TMPDIR)/outdir/$(NAME) $(TMPDIR)` but it used `ln -nsf outdir/$(NAME) $(TMPDIR)`. The rmake.rs version now explicitly separates the two directory trees and sets the CWD of the `bar.rs` rustc invocation so that the actual library is *not* present under its CWD tree.
I.e. it is now
```
$test_output/ # rustc foo.rs -o actual_lib_dir/libfoo.rlib
actual_lib_dir/
libfoo.rlib
symlink_lib_dir/ # CWD set; rustc -L . bar.rs
libfoo.rlib --> $test_output/actual_lib_dir/libfoo.rlib
```
Partially supersedes #129011.
This PR is co-authored with `@Oneirical.`
r? compiler
Migrate `branch-protection-check-IBT` to rmake.rs
- The Makefile version *never* ran because of Makefile syntax confusion because `ifeq ($(filter x86,$(LLVM_COMPONENTS)),x86_64)` [compares `x86` to `x86_64`, which always evaluates to false](https://github.com/rust-lang/rust/pull/126720#discussion_r1646808973).
- The test would've always failed because precompiled std is not built with `-Z cf-protection=branch`, but linkers require all input object files to indicate IBT support in order to enable IBT for the executable, which is not the case for std.
- Thus, the test input file is instead changed to a `no_std` program.
- The test is currently limited to only `x86_64-unknown-linux-gnu` host, there are various other problems when the test is cross-compiled that I didn't want to fix atm, and is left as an exercise for the `-Z cf-protection` implementers.
The GNU property note was added by #110304 in order to address #103001.
Partially supersedes #129156.
The rmake.rs port was initially authored by `@Rejyr` in #126720.
This PR is co-authored with `@Oneirical` and `@Rejyr.`
r? `@bjorn3` or reroll
try-job: x86_64-mingw-1
try-job: x86_64-mingw-2
try-job: x86_64-msvc
try-job: x86_64-apple-1
try-job: x86_64-apple-2
Implement `default_overrides_default_fields` lint
Detect when a manual `Default` implementation isn't using the existing default field values and suggest using `..` instead:
```
error: `Default` impl doesn't use the declared default field values
--> $DIR/manual-default-impl-could-be-derived.rs:14:1
|
LL | / impl Default for A {
LL | | fn default() -> Self {
LL | | A {
LL | | y: 0,
| | - this field has a default value
... |
LL | | }
| |_^
|
= help: use the default values in the `impl` with `Struct { mandatory_field, .. }` to avoid them diverging over time
note: the lint level is defined here
--> $DIR/manual-default-impl-could-be-derived.rs:5:9
|
LL | #![deny(default_overrides_default_fields)]
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
```
r? `@compiler-errors`
This is a simpler version of #134441, detecting the simpler case when a field with a default should have not been specified in the manual `Default::default()`, instead using `..` for it. It doesn't provide any suggestions, nor the checks for "equivalences" nor whether the value used in the imp being used would be suitable as a default field value.
