Some small nits to the borrowck suggestions for mutating a map through index
1. Suggesting users to either use `.insert` or `.get_mut` (which do totally different things) can be a bit of a footgun, so let's make that a bit more nuanced.
2. I find the suggestion of `.get_mut(|val| { *val = whatever; })` to be a bit awkward. I changed this to be an if-let instead.
3. Fix a bug which was suppressing the structured suggestion for some mutations via the index operator on `HashMap`/`BTreeMap`.
r? estebank or reassign
E0277: suggest dereferencing function arguments in more cases
This unifies and generalizes some of the logic in `TypeErrCtxt::suggest_dereferences` so that it will suggest dereferencing arguments to function/method calls in order to satisfy trait bounds in more cases.
Previously it would only fire on reference types, and it had two separate cases (one specifically to get through custom `Deref` impls when passing by-reference, and one specifically to catch #87437). I've based the new checks loosely on what's done for `E0308` in `FnCtxt::suggest_deref_or_ref`: it will suggest dereferences to satisfy trait bounds whenever the referent is `Copy`, is boxed (& so can be moved out of the boxes), or is being passed by reference.
This doesn't make the suggestion fire in contexts other than function arguments or binary operators (which are in a separate case that this doesn't touch), and doesn't make it suggest a combination of `&`-removal and dereferences. Those would require a bit more restructuring, so I figured just doing this would be a decent first step.
Closes#90997
borrowck diagnostics: make `add_move_error_suggestions` use the HIR rather than `SourceMap`
This PR aims to fix#132806 by rewriting `add_move_error_suggestions`[^1]. Previously, it manually scanned the source text to find a leading `&`, which isn't always going to produce a correct result (see: that issue). Admittedly, the HIR visitor in this PR introduces a lot of boilerplate, but hopefully the logic at its core isn't too complicated (I go over it in the comments). I also tried a simpler version that didn't use a HIR visitor and suggested adding `ref` always, but the `&ref x` suggestions really didn't look good. As a bonus for the added complexity though, it's now able to produce nice `&`-removing suggestions in more cases.
I tried to do this such that it avoids edition-dependent checks and its suggestions can be applied together with those from the match ergonomics 2024 migration lint. I haven't added tests for that since the details of match ergonomics 2024 are still being sorted out, but I can try if desired once that's finalized.
[^1]: In brief, it fires on patterns where users try to bind by-value in such a way that moves out of a reference to a non-Copy type (including slice references with non-copy elements). The suggestions are to change the binding's mode to be by-reference, either by removing[^2] an enclosing `&`/`&mut` or adding `ref` to the binding.
[^2]: Incidentally, I find the terminology of "consider removing the borrow" a bit confusing for a suggestion to remove a `&` pattern in order to make bindings borrow rather than move. I'm not sure what a good, concise way to explain that would be though, and that should go in a separate PR anyway.
```
error: `Default` impl doesn't use the declared default field values
--> $DIR/manual-default-impl-could-be-derived.rs:28:1
|
LL | / impl Default for B {
LL | | fn default() -> Self {
LL | | B {
LL | | x: s(),
| | --- this field has a default value
LL | | y: 0,
| | - this field has a default value
... |
LL | | }
| |_^
|
help: to avoid divergence in behavior between `Struct { .. }` and `<Struct as Default>::default()`, derive the `Default`
|
LL ~ #[derive(Default)] struct B {
|
```
Note that above the structured suggestion also includes completely removing the manual `impl`, but the rendering doesn't.
Account for C string literals and `format_args` in `HiddenUnicodeCodepoints` lint
This is stacked on #134955, and either that can land first or both of them can land together here. I split this out because this is a bit more involved of an impl.
Fixes#94945
Windows: Enable issue 70093 link tests
Tracking issue for `-Z link-native-libraries`: #134948
Tracking issue for `-Z link-directives`: #134947
`-Zlink-native-libraries=no` and `-Zlink-directives=no` *should* work on Windows, at least for msvc. The fly in ointment is that `default-linker-libraries` doesn't. On unixy platforms rustc calls another compiler which in turn calls the linker along with the default libraries. On MSVC rustc calls the linker directly therefore it would need to be the one to implement `default-linker-libraries`. Except it doesn't so we workaround that in the test by using `-C link-arg` to talk to the linker.
Unsafe binder support in rustdoc
Adds rustdoc support for unsafe binder types: `unsafe<'a> Foo<'a>`. Doesn't add json support yet.
Tracking:
* https://github.com/rust-lang/rust/issues/130516
stabilize const_swap
libs-api FCP passed in https://github.com/rust-lang/rust/issues/83163.
However, I only just realized that this actually involves an intrinsic. The intrinsic could be implemented entirely with existing stable const functionality, but we choose to make it a primitive to be able to detect more UB. So nominating for `@rust-lang/lang` to make sure they are aware; I leave it up to them whether they want to FCP this.
While at it I also renamed the intrinsic to make the "nonoverlapping" constraint more clear.
Fixes#83163
tests: add basic test coverage for stable `--crate-type` flag
I experimented locally with making the compiler panic if multiple crate types are passed to a single `--crate-type` flag, and it turns out not only does the compiler successfully bootstrap, only two ui tests failed:
```
failures:
[ui] tests/ui/sepcomp/sepcomp-lib.rs
[ui] tests/ui/sepcomp/sepcomp-lib-lto.rs
test result: FAILED. 4 passed; 2 failed; 18181 ignored; 0 measured; 0 filtered out; finished in 364.55ms
```
These are not specific tests for the `--crate-type` flag, only their auxiliary *happens* to use a `--crate-type` with two crate types:
```rs
//@ compile-flags: -C codegen-units=3 --crate-type=rlib,dylib -g
```
I was not able to find a specific test in run-make test suite either.
So this PR tries to add some basic test coverage for the stable `--crate-type` flag's interface (including to check that `--crate-type` accepts multiple crate types), since I imagine it might be slightly awkward if we accidentally regressed this.
r? compiler
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.
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.
- The Makefile version *never* ran because of Makefile syntax confusion.
- 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` + `no_core`
program.
Co-authored-by: Jerry Wang <jerrylwang123@gmail.com>
Co-authored-by: Oneirical <manchot@videotron.ca>
- 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 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)`.
Co-authored-by: Oneirical <manchot@videotron.ca>
