compiletest: Support matching on diagnostics without a span
Using `//~? ERROR my message` on any line of the test.
The new checks are exhaustive, like all other `//~` checks, and unlike the `error-pattern` directive that is sometimes used now to check for span-less diagnostics.
This will allow to eliminate most on `error-pattern` directives in compile-fail tests (except those that are intentionally imprecise due to platform-specific diagnostics).
I didn't migrate any of `error-pattern`s in this PR though, except those where the migration was necessary for the tests to pass.
Fix/tweak some tests in new solver
Bunch of miscellaneous new solver tweaks that I found from the failing tests. Can split these out, but they all seemed small enough to not warrant separate PRs.
r? lcnr
Reintroduce remote-test support in run-make tests
The old Makefile-based infrastructure included support for executing binaries with remote-test-client if configured, but that didn't get ported to run_make_support as part of the rmake migration.
This PR re-introduces back that support, with the same implementation (and limitations) of the original Makefile-based support.
[Old Makefile-based implementation of this](9b8accbeb6/tests/run-make/tools.mk (L65-L74))
try-job: armhf-gnu
Lower to a memset(undef) when Rvalue::Repeat repeats uninit
Fixes https://github.com/rust-lang/rust/issues/138625.
It is technically correct to just do nothing. But if we actually do nothing, we may miss that this is de-initializing something, so instead we just lower to a single memset that writes undef. This is still superior to the memcpy loop, in both quality of code we hand to the backend and LLVM's final output.
Lower BinOp::Cmp to llvm.{s,u}cmp.* intrinsics
Lowers `mir::BinOp::Cmp` (`three_way_compare` intrinsic) to the corresponding LLVM `llvm.{s,u}cmp.i8.*` intrinsics.
These are the intrinsics mentioned in https://github.com/rust-lang/rust/pull/118310, which are now available in LLVM 19.
I couldn't find any follow-up PRs/discussions about this, please let me know if I missed something.
r? `@scottmcm`
I saw someone post a code sample that contained these two attributes,
which immediately made me suspicious.
My suspicions were confirmed when I did a small test and checked the
compiler source code to confirm that in these cases, `#[inline]` is
indeed ignored (because you can't exactly `LocalCopy`an unmangled symbol
since that would lead to duplicate symbols, and doing a mix of an
unmangled `GloballyShared` and mangled `LocalCopy` instantiation is too
complicated for our current instatiation mode logic, which I don't want
to change right now).
So instead, emit the usual unused attribute lint with a message saying
that the attribute is ignored in this position.
I think this is not 100% true, since I expect LLVM `inlinehint` to still
be applied to such a function, but that's not why people use this
attribute, they use it for the `LocalCopy` instantiation mode, where it
doesn't work.
This fixes two problems with the autofixes for the `unused_imports`
lint:
- `use std::collections::{HashMap, self as coll};` would suggest, when
`HashMap` is unused, the incorrect `use std::collections::self as coll;`
which does not compile.
- `use std::borrow::{self, Cow};` would suggest, when `self` is unused,
`use std::borrow::{Cow};`, which contains unnecessary brackets.
The newly added pattern types validity tests fail on s390x and
presumably other big-endian systems, due to print of raw values
with padding bytes.
To fix the tests remove the raw output values in the error note by
`normalize-stderr`.
rustdoc: be more strict about "Methods from Deref"
fixes#137083fixes#24686
Currently done:
* [x] fix `render_assoc_items_inner
* [x] fix sidebar logic
* [x] port test from https://github.com/rust-lang/rust/pull/137564
* [x] add test for sidebar items
Note that this does not yet fix the sidebar logic.
Simplify `PartialOrd` on tuples containing primitives
We noticed in https://github.com/rust-lang/rust/pull/133984#issuecomment-2704011800 that currently the tuple comparison code, while it [does optimize down](https://github.com/rust-lang/rust/blob/master/tests/codegen/comparison-operators-2-tuple.rs) today, is kinda huge: <https://rust.godbolt.org/z/xqMoeYbhE>
This PR changes the tuple code to go through an overridable "chaining" version of the comparison functions, so that for simple things like `(i16, u16)` and `(f32, f32)` (as seen in the new MIR pre-codegen test) we just directly get the
```rust
if lhs.0 == rhs.0 { lhs.0 OP rhs.0 }
else { lhs.1 OP rhs.1 }
```
version in MIR, rather than emitting a mess for LLVM to have to clean up.
Test added in the first commit, so you can see the MIR diff in the second one.
Add unstable `--print=supported-crate-types` option
MCP: https://github.com/rust-lang/compiler-team/issues/836
Tracking issue: https://github.com/rust-lang/rust/issues/138640
### Test coverage
Two tests:
1. `tests/ui/print-request/stability.rs` to check that `--print=supported-crate-types` is `-Zunstable-options`-gated
2. `tests/ui/print-request/supported-crate-types.rs` is added as a basic smoke test. Observe that the compiler stdout corresponds to the below *Example output* section (e.g. `proc-macro` is unsupported on `wasm32-unknown-unknown` currently).
### Example output
<details>
<summary>For `x86_64-unknown-linux-gnu`</summary>
Notice the presence of `{c,}dylib` and `proc-macro`:
```
bin
cdylib
dylib
lib
proc-macro
rlib
staticlib
```
</details>
<details>
<summary>For `wasm32-unknown-unknown`</summary>
Notice the absence of `dylib` and `proc-macro`:
```
bin
cdylib
lib
rlib
staticlib
```
</details>
<details>
<summary>For `x86_64-unknown-linux-musl`</summary>
Notice the absence of `{c,}dylib` but presence of `proc-macro`:
```
bin
lib
proc-macro
rlib
staticlib
```
</details>
### Documentation
I added an entry in the unstable book's print request section to document this `supported-crate-types` print request.
### Unresolved questions
- [ ] (Name bikeshedding) is `supported-crate-types` a good name for the print request? I'm inclined to say it's good enough for an unstable print request, but may be worth revisiting at stabilization time.
### Stability
This print request being added is *unstable* in this PR. A separate stabilization PR following the usual compiler flag stabilization procedure should be filed for stabilization after some baking time.
### Review remarks
Best reviewed commit-by-commit.
r? compiler
Add MIR pre-codegen tests to track #138544
I don't know how best to fix the problem yet, but wanted to check in some tests to demonstrate it and make sure that they get updated to keep it fixed if anyone does fix it 🙂
No code changes; just the tests for #138544.
rustdoc: Gate unstable `doc(cfg())` predicates
Fixes#138113
Since the extraction process treats `cfg(true)` as having no cfg attribute, we have to do the gating during parsing; so we remove the unused `features` arg from `Cfg::matches`
- Document test intent to check for `-Whelp` suggestion if
`--print=lints` was specified.
- Move this test under `tests/ui/print-request/` and rename it to
`print-lints-help.rs` to better reflect what it is checking.
Move some driver code around
`--emit mir`, `#[rustc_symbol_name]` and `#[rustc_def_path]` now run before codegen and thus work even if codegen fails. This can help with debugging.
hack: is_doc_subtype_of always returns true for TyAlias
it's worth noting that this function is only used in
the handling of "Methods from Deref", and we were previously
assuming all generic parameters were meaningless,
so this is still an improvment from the status quo.
this change means that we will have strictly less false positives
without adding any new false negitives.
Co-authored-by: Guillaume Gomez <guillaume1.gomez@gmail.com>
