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>
Skip parenthesis around tuple struct field calls
The pretty-printer previously did not distinguish between named vs unnamed fields when printing a function call containing a struct field. It would print the call as `(self.fun)()` for a named field which is correct, and `(self.0)()` for an unnamed field which is redundant.
This PR changes function calls of tuple struct fields to print without parens.
**Before:**
```rust
struct Tuple(fn());
fn main() {
let tuple = Tuple(|| {});
(tuple.0)();
}
```
**After:**
```rust
struct Tuple(fn());
fn main() {
let tuple = Tuple(|| {});
tuple.0();
}
```
Skip parenthesis if `.` makes statement boundary unambiguous
There is a rule in the parser that statements and match-arms never end in front of a `.` or `?` token (except when the `.` is really `..` or `..=` or `...`). So some of the leading subexpressions that need parentheses inserted when followed by some other operator like `-` or `+`, do not need parentheses when followed by `.` or `?`.
Example:
```rust
fn main() {
loop {}.to_string() + "";
match () {
_ => loop {}.to_string() + "",
};
}
```
`-Zunpretty=expanded` before:
```console
#![feature(prelude_import)]
#[prelude_import]
use std::prelude::rust_2021::*;
#[macro_use]
extern crate std;
fn main() {
(loop {}).to_string() + "";
match () { _ => (loop {}).to_string() + "", };
}
```
After:
```console
#![feature(prelude_import)]
#[prelude_import]
use std::prelude::rust_2021::*;
#[macro_use]
extern crate std;
fn main() {
loop {}.to_string() + "";
match () { _ => loop {}.to_string() + "", };
}
```
Make `ty::Error` implement all auto traits
I have no idea what's up with the crashes test I fixed--I really don't want to look into it since it has to do something with borrowck and multiple layers of opaques. I think the underlying idea of allowing error types to implement all auto traits is justified though.
Fixes#134796Fixes#131050
r? lcnr
Add a compiler intrinsic to back `bigint_helper_methods`
cc https://github.com/rust-lang/rust/issues/85532
This adds a new `carrying_mul_add` intrinsic, to implement `wide_mul` and `carrying_mul`.
It has fallback MIR for all types -- including `u128`, which isn't currently supported on nightly -- so that it'll continue to work on all backends, including CTFE.
Then it's overridden in `cg_llvm` to use wider intermediate types, including `i256` for `u128::carrying_mul`.
rustdoc: use shorter paths as preferred canonical paths
This is a solution to [the `std::sync::poison` linking problem](https://github.com/rust-lang/rust/pull/134692#issuecomment-2560373308), and, in general, makes intra-doc links shorter and clearer.
> Done. This helped with the search, but not with the things like `MutexGuard`'s doc's reference to `Mutex::lock` being converted to the absolute (unstable) `std::sync::poison::Mutex` path.
cc `@tgross35`
r? `@GuillaumeGomez`
Spruce up the docs of several queries related to the type/trait system and const eval
- Editorial
- Proper rustdoc summary/synopsis line by making use of extra paragraphs: Leads to better rendered output on module pages, in search result lists and overall, too
- Use rustdoc warning blocks for admonitions of the form "do not call / avoid calling this query directly"
- Use intra-doc links of the form ``[`Self::$query`]`` to cross-link queries. Indeed, such links are generally a bit brittle due to the existence of `TyCtxtFeed` which only contains a subset of queries. Therefore the docs of `feedable` queries cannot cross-link to non-`feedable` ones. I'd say it's fine to use intra-doc links despite the potential/unlikely occasional future breakage (if a query with the aforementioned characteristics becomes `feedable`). `Self::` is nicer than `TyCtxt::` (which would be more stable) since it accounts for other contexts like `TyCtxt{Feed,At,Ensure{,WithValue}}`
- Informative
- Generally add, flesh out and correct some doc comments
- Add *Panic* sections (to a few selected queries only). The lists of panics aren't necessarily exhaustive and focus on the more "obvious" or "important" panics.
- Where applicable add a paragraph calling attention to the relevant [`#[rustc_*]` TEST attribute](https://rustc-dev-guide.rust-lang.org/compiler-debugging.html#rustc_-test-attributes)
The one non-doc change (it's internal and not observable):
Be even more defensive in `query constness`'s impl (spiritual follow-up to #134122) (see self review comment).
Fixes#133494.
r\? **any**(compiler-errors, oli-obk)
compiletest: Remove the `-test` suffix from normalize directives
This suffix was an artifact of using the same condition-checking engine as the `ignore-*` and `only-*` directives, but in practice we have only 2 tests that legitimately use a condition, and both of them only care about 32-bit vs 64-bit.
This PR detaches `normalize-*` directives from the condition checker, and replaces it with a much simpler system of four explicit `NormalizeKind` values. It then takes advantage of that simplicity to get rid of the `-test` suffix.
---
Addresses one of the points of #126372.
The new name-checking code is a bit quaint, but I think it's a definite improvement over the status quo.
---
The corresponding dev-guide update is https://github.com/rust-lang/rustc-dev-guide/pull/2172.
r? jieyouxu
