Const Compare for Tuples
Makes the impls for Tuples of ~const `PartialEq` types also `PartialEq`, impls for Tuples of ~const `PartialOrd` types also `PartialOrd`, for Tuples of ~const `Ord` types also `Ord`.
behind the `#![feature(const_cmp)]` gate.
~~Do not merge before #104113 is merged because I want to use this feature to clean up the new test that I added there.~~
r? ``@fee1-dead``
Don't intra linkcheck reference
This removes the reference from the intra-doc link checks. This causes problems if any of the reference content needs to change, it causes the linkchecker to break. The reference has its own broken link check (https://github.com/rust-lang/reference/tree/master/style-check) which uses pulldown-cmark on the source to find actual broken links (instead of false-positives like this regex does).
I think the intra-doc link check could potentially be removed completely, since I think rustdoc is now checking for them well enough. However, it may serve as a decent regression check.
Refactor build-manifest to minimize the number of changes needed to add a new component
- Add all components to `PkgType`
- Automate functionality wherever possible, so functions often don't have to be manually edited
- Where that's not possible, use exhaustive matches on `PkgType` instead of adding individual strings.
- Add documentation for how to add a component. Improve the existing documentation for how to test changes.
I tested locally that this generates an identical manifest before and after my change, as follows:
```sh
git checkout d44e14225ab00e164aa9ea9e8d9e1bee40f96b3e
cargo +nightly run --manifest-path src/tools/build-manifest/Cargo.toml build/dist build/manifest-before 1970-01-01 http://example.com nightly
git checkout refactor-build-manifest
cargo +nightly run --manifest-path src/tools/build-manifest/Cargo.toml build/dist build/manifest-before 1970-01-01 http://example.com nightly
sort -u build/manifest-before/channel-rust-nightly.toml | diff - <(sort -u build/manifest-after/channel-rust-nightly.toml)
```
I then verified by hand that the differences before sorting are inconsequential (mostly targets being slightly reordered).
The only change in behavior is that `llvm-tools` is now properly renamed to `llvm-tools-preview`:
```
; sort -u build/manifest-before/channel-rust-nightly.toml | diff - <(sort -u build/manifest-after/channel-rust-nightly.toml)
784a785
> [renames.llvm-tools]
894a896
> to = "llvm-tools-preview"
```
This is based on https://github.com/rust-lang/rust/pull/102241 and should not be merged before.
Remove #![allow(rustc::potential_query_instability)] from rustc_infer
Related to #84447
This PR probably needs to be benchmarked to check for regressions.
[debuginfo] Make cpp-like debuginfo type names for slices and str consistent.
Before this PR, the compiler would emit the debuginfo name `slice$<T>` for all kinds of slices, regardless of whether they are behind a reference or not and regardless of the kind of reference. As a consequence, the types `Foo<&[T]>`, `Foo<[T]>`, and `Foo<&mut [T]>` would end up with the same type name `Foo<slice$<T> >` in debuginfo, making it impossible to disambiguate between them by name. Similarly, `&str` would get the name `str` in debuginfo, so the debuginfo name for `Foo<str>` and `Foo<&str>` would be the same. In contrast, `*const [bool]` and `*mut [bool]` would be `ptr_const$<slice$<bool> >` and `ptr_mut$<slice$<bool> >`, i.e. the encoding does not lose information about the type.
This PR removes all special handling for slices and `str`. The types `&[bool]`, `&mut [bool]`, and `&str` thus get the names `ref$<slice2$<bool> >`, `ref_mut$<slice2$<bool> >`, and `ref$<str$>` respectively -- as one would expect.
The new special name for slices is `slice2$` to differentiate it from the previous name `slice$`, which has different semantics. The same is true for `str` and `str$`. This kind of versioning already has a precedent with the case of `enum$` and `enum2$` and hopefully will make it easier to transition existing consumers of these names.
cc `@rust-lang/wg-debugging` `@vadimcn`
r? `@wesleywiser`
UPDATE: Here is a table to clarify the changes
| Rust type | DWARF name | C++-like name (before) | C++-like name (after) |
|-----------|------------|------------------------|------------------------|
| `[T]` | `[T]` | `slice$<T>` | `slice2$<T>` |
| `&[T]` | `&[T]` | `slice$<T>` | `ref$<slice2$<T> >` |
| `&mut [T]` | `&mut [T]` | `slice$<T>` | `ref_mut$<slice2$<T> >`|
| `str` | `str` | `str` | `str$` |
| `&str` | `&str` | `str` | `ref$<str$>` |
| `&mut str` | `&mut str` | `str` | `ref_mut$<str$>`|
| `*const [T]` | `*const [T]` | `ptr_const$<slice$<T> >` | `ptr_const$<slice2$<T> >` |
| `*mut [T]` | `*mut [T]` | `ptr_mut$<slice$<T> >` | `ptr_mut$<slice2$<T> >` |
As you can see, before the PR many types would end up with the same name, making it impossible to distinguish between them in NatVis or other places where types are matched or looked up by name. The DWARF version of names is not changed.
Ensure that compile-flags arguments are the last in UI tests
Before this PR, compiletest would add `-L path/to/aux` at the end of the rustc flags, even after the custom ones set with the compile-flags header comment. This made it impossible to check how rustc would behave when a flag requiring an argument was passed without the argument, because the argument would become `-L`.
This PR fixes that by adding the `-L path/to/aux` before the arguments defined in compile-flags, at least for UI tests. Other test suites might either be fixed as well by this change, or still present the old behavior (`-L` is now always passed before, but other tests suites might add additional flags after the custom ones).
Add QEMU test for x86_64-unknown-uefi
The UEFI targets don't have std support yet, so the normal tests don't work. However, we can compile a simple no-std program and run it under QEMU to at least check that the target compiles, links, and runs.
Tested locally with: `src/ci/docker/run.sh x86_64-uefi`
asm: Match clang behavior for inlateout fixed register operands
We have 2 options for representing LLVM constraints for `inlateout` operands on a fixed register (e.g. `r0`): `={r0},0` or `={r0},{r0}`.
This PR changes the behavior to the latter, which matches the behavior of Clang since https://reviews.llvm.org/D87279.
Fixed consistency of Apple simulator target's ABI
Currently there's a few Apple device simulator targets that are inconsistent since some set `target_abi = "sim"` (the correct thing to do) while a bunch of others don't set anything (`""`). Due to this its very hard to reliability check if some Rust code is running inside a simulator. This changes all of them to do the same thing and set `sim` as their `target_abi`.
The new way to identity a simulator during compilation is as simple as `cfg(all(target_vendor="apple", target_abi = "sim"))` or even `cfg(target_abi = "sim")` being less pedantic about it.
The issues with the current form (and inspiration for this) are also summarized in `@thomcc's` [Tweet](https://twitter.com/at_tcsc/status/1576685244702691328).
rustdoc: Do not add external traits to the crate in `register_res`
It's not clear why it was done, and apparently it's no longer necessary now.
Such additions are unpredictable for early doc link resolution and would force us to collect all doc links from all external traits.
Fixes https://github.com/rust-lang/rust/issues/103463
Track where diagnostics were created.
This implements the `-Ztrack-diagnostics` flag, which uses `#[track_caller]` to track where diagnostics are created. It is meant as a debugging tool much like `-Ztreat-err-as-bug`.
For example, the following code...
```rust
struct A;
struct B;
fn main(){
let _: A = B;
}
```
...now emits the following error message:
```
error[E0308]: mismatched types
--> src\main.rs:5:16
|
5 | let _: A = B;
| - ^ expected struct `A`, found struct `B`
| |
| expected due to this
-Ztrack-diagnostics: created at compiler\rustc_infer\src\infer\error_reporting\mod.rs:2275:31
```
Don't use usub.with.overflow intrinsic
The canonical form of a usub.with.overflow check in LLVM are separate sub + icmp instructions, rather than a usub.with.overflow intrinsic. Using usub.with.overflow will generally result in worse optimization potential.
The backend will attempt to form usub.with.overflow when it comes to actual instruction selection. This is not fully reliable, but I believe this is a better tradeoff than using the intrinsic in IR.
Fixes#103285.
ci: Bring back ninja for dist builders
The primary reason for this is that make can result in a substantial under utilization of parallelism (noticed while testing on a workstation), mostly due to the submake structure preventing good dependency tracking and scheduling.
In f758c7b2a78 (Debian 6 doesn't have ninja, so use make for the dist builds) llvm.ninja was disabled due to lack of distro package. This is no longer the case with the CentOS 7 base, so bring ninja back for a performance boost.
Clean up tests and add documentation for GATs related stuff
This is a follow-up PR for #13494.
- addresses https://github.com/rust-lang/rust-analyzer/pull/13494#discussion_r1006774897
- documents the ordering constraint on `Binders` and `Substitution` (which is not really follow-up for the previous PR, but it was introduced to support GATs and I strongly feel it's worth it)
Introduce UnordMap, UnordSet, and UnordBag (MCP 533)
This is the start of implementing [MCP 533](https://github.com/rust-lang/compiler-team/issues/533).
I followed `@eddyb's` suggestion of naming the collection types `Unord(Map/Set/Bag)` which is a bit easier to type than `Unordered(Map/Set/Bag)`
r? `@eddyb`
privacy: Rename "accessibility levels" to "effective visibilities"
And a couple of other naming and comment tweaks.
Related to https://github.com/rust-lang/rust/issues/48054
For `enum Level` I initially used naming `enum EffectiveVisibilityLevel`, but it was too long and inconvenient because it's used pretty often.
So I shortened it to just `Level`, if it needs to be used from some context where this name would be ambiguous, then it can be imported with renaming like `use rustc_middle::privacy::Level as EffVisLevel` or something.
poll_fn and Unpin: fix pinning
See [IRLO](https://internals.rust-lang.org/t/surprising-soundness-trouble-around-pollfn/17484) for details: currently `poll_fn` is very subtle to use, since it does not pin the closure, so creating a `Pin::get_unchcked(&mut capture)` inside the closure is unsound. This leads to actual miscompilations with `futures::join!`.
IMO the proper fix is to pin the closure when the future is pinned, which is achieved by changing the `Unpin` implementation. This is a breaking change though. 1.64.0 was *just* released, so maybe this is still okay?
The alternative would be to add some strong comments to the docs saying that closure captures are *not pinned* and doing `Pin::get_unchecked` on them is unsound.
Fix line numbers for MIR inlined code
`should_collapse_debuginfo` detects if the specified span is part of a
macro expansion however it does this by checking if the span is anything
other than a normal (non-expanded) kind, then the span sequence is
walked backwards to the root span.
This doesn't work when the MIR inliner inlines code as it creates spans
with expansion information set to `ExprKind::Inlined` and results in the
line number being attributed to the inline callsite rather than the
normal line number of the inlined code.
Fixes#103068
