Commit Graph

13196 Commits

Author SHA1 Message Date
Olivier Goffart 5d456dfaa1 Use `#[doc(hidden)]` instead of `#[allow(missing_docs)]` on the const generated for `#[test]` 2024-09-11 11:49:27 +02:00
Olivier Goffart 6eddbb704e Fix false positive with `missing_docs` and `#[test]`
Since #130025, the compiler don't ignore missing_docs when compiling the tests.
But there is now a false positive warning for every `#[test]`

For example, this code
```rust
//! Crate docs

fn just_a_test() {}
```

Would emit this warning when running `cargo test`

```
warning: missing documentation for a constant
 --> src/lib.rs:5:1
  |
4 | #[test]
  | ------- in this procedural macro expansion
5 | fn just_a_test() {}
  | ^^^^^^^^^^^^^^^^^^^
```
2024-09-11 11:33:10 +02:00
bors 5a2dd7d4f3 Auto merge of #130194 - lcnr:generalize-cache, r=compiler-errors
generalize: track relevant info in cache key

This was previously theoretically incomplete as we could incorrectly generalize as if the type was in an invariant context even though we're in a covariant one. Similar with the `in_alias` flag.

r? `@compiler-errors`
2024-09-11 07:17:12 +00:00
bors 4c5fc2c334 Auto merge of #130050 - cjgillot:expect-attr-id, r=fee1-dead
Enumerate lint expectations using AttrId

This PR implements the idea I outlined in https://github.com/rust-lang/rust/issues/127884#issuecomment-2240338547

We can uniquely identify a lint expectation `#[expect(lint0, lint1...)]` using the `AttrId` and the index of the lint inside the attribute. This PR uses this property in `check_expectations`.

In addition, this PR stops stashing expected diagnostics to wait for the unstable -> stable `LintExpectationId` mapping: if the lint is emitted with an unstable attribute, it must have been emitted by an `eval_always` query (like inside the resolver), so won't be loaded from cache. Decoding an `AttrId` from the on-disk cache ICEs, so we have no risk of accidentally checking an expectation.

Fixes https://github.com/rust-lang/rust/issues/127884

cc `@xFrednet`
2024-09-11 04:49:56 +00:00
Ralf Jung e556c136f3 clean up internal comments about float semantics
- remove an outdated FIXME
- add reference to floating-point semantics issue

Co-authored-by: Jubilee <workingjubilee@gmail.com>
2024-09-10 16:47:09 -07:00
Ralf Jung 3daa9518d5 enable and extend float-classify test 2024-09-10 16:47:01 -07:00
Jubilee Young c40ee79b84 move float tests into their own dir 2024-09-10 16:05:37 -07:00
bors 6f7229c4da Auto merge of #129403 - scottmcm:only-array-simd, r=compiler-errors
Ban non-array SIMD

Nearing the end of https://github.com/rust-lang/compiler-team/issues/621 !

Currently blocked on ~~https://github.com/rust-lang/compiler-builtins/pull/673~~ ~~https://github.com/rust-lang/compiler-builtins/pull/674~~ ~~https://github.com/rust-lang/rust/pull/129400~~ ~~https://github.com/rust-lang/rust/pull/129481~~ for windows.
2024-09-10 22:47:40 +00:00
FedericoBruzzone 4cecf42971 Report the `note` when specified in `diagnostic::on_unimplemented`
Signed-off-by: FedericoBruzzone <federico.bruzzone.i@gmail.com>
2024-09-10 23:05:36 +02:00
bors 0ee7cb5e36 Auto merge of #130200 - matthiaskrgr:rollup-2g4ijc5, r=matthiaskrgr
Rollup of 5 pull requests

Successful merges:

 - #130143 (miri-test-libstd: add missing BOOTSTRAP_ARGS)
 - #130173 (rustdoc: add two regression tests)
 - #130175 (`rustc_mir_transform` cleanups 3)
 - #130184 (coverage: Clean up terminology in counter creation)
 - #130185 (abi/compatibility test: remove tests inside repr(C) wrappers)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-09-10 20:18:27 +00:00
Ding Xiang Fei 89682a5313
downgrade borrowck suggestion level due to possible span conflict 2024-09-11 04:10:04 +08:00
Ding Xiang Fei e2120a7c38
coalesce lint suggestions that can intersect 2024-09-11 04:10:03 +08:00
Ding Xiang Fei f93df1f7dc
rescope temp lifetime in let-chain into IfElse
apply rules by span edition
2024-09-11 04:10:00 +08:00
Paul Menage 3810386bbe Add -Z small-data-threshold
This flag allows specifying the threshold size above which LLVM should
not consider placing small objects in a .sdata or .sbss section.

Support is indicated in the target options via the
small-data-threshold-support target option, which can indicate either an
LLVM argument or an LLVM module flag.  To avoid duplicate specifications
in a large number of targets, the default value for support is
DefaultForArch, which is translated to a concrete value according to the
target's architecture.
2024-09-10 12:19:16 -07:00
Matthias Krüger a42d67e6cc
Rollup merge of #130185 - RalfJung:abi-compat-repr-c-wrappers, r=compiler-errors
abi/compatibility test: remove tests inside repr(C) wrappers

When I wrote the test I assumed we'd guarantee ABI compatibility to be "structural" wrt `repr(C)` types, i.e. if two `repr(C)` types have all their fields be pairwise ABI-compatible then the types are ABI-compatible. That got removed from the ABI compatibility docs before they landed, though, so let's also remove it from this test.
2024-09-10 17:35:16 +02:00
Matthias Krüger a204f87de8
Rollup merge of #130173 - fmease:rustdoc-regression-tests, r=notriddle
rustdoc: add two regression tests

They were basically copy/pasted from `tests/ui/` to `tests/rustdoc-ui/`.
Not sure if it's worth adding these, I can just close these issues as is if you want.

This brings the number of https://github.com/rust-lang/rust/labels/T-rustdoc + https://github.com/rust-lang/rust/labels/E-needs-test from 3 down to 1.
The remaining one – #103004 — is a nasty one to retroactively find a proper(!) test for.

Fixes #98250.
Fixes #107872.

r? rustdoc
2024-09-10 17:35:14 +02:00
Florian Schmiderer 713828d4f4 Add test for S_OBJNAME and update test for LF_BUILDINFO cl and cmd for
pdb files.
2024-09-10 17:23:05 +02:00
Michael Goulet 5cf117ed05 Don't call closure_by_move_body_def_id on FnOnce async closures in MIR validation 2024-09-10 10:55:05 -04:00
bors 33855f80d4 Auto merge of #130025 - Urgau:missing_docs-expect, r=petrochenkov
Also emit `missing_docs` lint with `--test` to fulfil expectations

This PR removes the "test harness" suppression of the `missing_docs` lint to be able to fulfil `#[expect]` (expectations) as it is now "relevant".

I think the goal was to maybe avoid false-positive while linting on public items under `#[cfg(test)]` but with effective visibility we should no longer have any false-positive.

Another possibility would be to query the lint level and only emit the lint if it's of expect level, but that is even more hacky.

Fixes https://github.com/rust-lang/rust/issues/130021

try-job: x86_64-gnu-aux
2024-09-10 14:54:09 +00:00
lcnr 7a57a74bf5 generalize: track relevant info in cache key 2024-09-10 15:21:57 +02:00
Folkert de Vries 6ca5ec7b4e disallow `naked_asm!` outside of `#[naked]` functions 2024-09-10 15:19:14 +02:00
Ralf Jung 86075759cc abi/compatibility test: remove tests inside repr(C) wrappers 2024-09-10 13:18:20 +02:00
bors f827364a95 Auto merge of #129337 - EtomicBomb:rfc, r=notriddle
rustdoc rfc#3662 changes under unstable flags

* All new functionality is under unstable options
* Adds `--merge=shared|none|finalize` flags
* Adds `--parts-out-dir=<crate specific directory>` for `--merge=none`
to write cross-crate info file for a single crate
* Adds `--include-parts-dir=<previously specified directory>` for
`--merge=finalize` to write cross-crate info files
* `tests/rustdoc/` tests for the new flags
2024-09-10 11:15:51 +00:00
Ralf Jung 123757ae07 turn errors that should be impossible due to our static checks into ICEs 2024-09-10 10:27:30 +02:00
Ralf Jung f76f128dc9 const-eval interning: accpt interior mutable pointers in final value (but keep rejecting mutable references) 2024-09-10 10:26:16 +02:00
Zalathar e96b4e479a coverage: Extract `executor::block_on` from several async coverage tests
By moving `block_on` to an auxiliary crate, we avoid having to keep a separate
copy of it in every async test.

(This also incorporates some small tweaks to the headers in `await_ready.rs`.)
2024-09-10 16:08:36 +10:00
Scott McMurray d2309c2a9d Ban non-array SIMD 2024-09-09 19:39:43 -07:00
Jubilee a26c809e7a
Rollup merge of #130152 - krasimirgg:nsan, r=nikic
adapt a test for llvm 20

No functional changes intended.

``@rustbot`` label: +llvm-main
r? ``@nikic``
2024-09-09 19:20:38 -07:00
Jubilee 57273d82a8
Rollup merge of #130146 - folkertdev:bootstrap-naked-asm, r=Amanieu
bootstrap `naked_asm!` for `compiler-builtins`

tracking issue: https://github.com/rust-lang/rust/issues/90957
parent PR: https://github.com/rust-lang/rust/pull/128651

in this PR, `naked_asm!` is added as an alias for `asm!` with one difference: `options(noreturn)` is always enabled by `naked_asm!`. That makes it future-compatible for when `naked_asm!` starts disallowing `options(noreturn)` later.

The `naked_asm!` macro must be introduced first so that we can upgrade `compiler-builtins` to use it, and can then change the implementation of `naked_asm!` in https://github.com/rust-lang/rust/pull/128651

I've added some usages for `naked_asm!` in the tests, so we can be confident that it works, but I've left upgrading the whole test suite to the parent PR.

r? ``@Amanieu``
2024-09-09 19:20:38 -07:00
Jubilee 2859c24e64
Rollup merge of #130094 - workingjubilee:concurrency-is-real, r=lcnr
Inform the solver if evaluation is concurrent

Parallel compilation of a program can cause unexpected event sequencing. Inform the solver when this is true so it can skip invalid asserts.
2024-09-09 19:20:37 -07:00
Jubilee a4c61048d8
Rollup merge of #129529 - lqd:stable-new-solver, r=Kobzol
Add test to build crates used by r-a on stable

r? ````````@Kobzol````````

I've opened other PRs for this one to work and they've landed already. I cherry-picked your commit, and added the last remaining pieces we needed I think.
2024-09-09 19:20:36 -07:00
León Orell Valerian Liehr 6d61dfd2e4
rustdoc: add two regression tests 2024-09-09 22:35:10 +02:00
Jubilee Young d243c8fbc4 compiler: Inform the solver of concurrency
Parallel compilation of a program can cause unexpected event sequencing.
Inform the solver when this is true so it can skip invalid asserts, then
assert replaced solutions are equal if Some
2024-09-09 13:07:48 -07:00
Matthias Krüger 3b0221bf63
Rollup merge of #130137 - gurry:master, r=cjgillot
Fix ICE caused by missing span in a region error

Fixes #130012

The ICE occurs on line 634 in this error handling code: 085744b7ad/compiler/rustc_trait_selection/src/error_reporting/infer/region.rs (L617-L637) It is caused by the span being a dummy span and `!span.is_dummy()` on line 628 evaluating to `false`.

A dummy span, however, is expected here thanks to the `Self: Trait` predicate from `predicates_of` (see line 61): 085744b7ad/compiler/rustc_hir_analysis/src/collect/predicates_of.rs (L61-L69)

This PR changes the error handling code to omit the note which needed the span instead of ICE'ing in the presence of a dummy span.
2024-09-09 20:20:20 +02:00
Matthias Krüger 1490fe6d16
Rollup merge of #130064 - folkertdev:fix-issue-129983, r=compiler-errors
fix ICE in CMSE type validation

fixes #129983

tracking issue: https://github.com/rust-lang/rust/issues/81391

r? ``@compiler-errors``
2024-09-09 20:20:18 +02:00
Krasimir Georgiev 383f506227 adapt a test for llvm 20
No functional changes intended.
2024-09-09 13:29:47 +00:00
Urgau 0f9cb070bc Add test about missing docs at crate level 2024-09-09 14:51:39 +02:00
Urgau a1a8627dd7 Allow `missing_docs` lint on the generated test harness 2024-09-09 14:51:39 +02:00
Mads Marquart dd35398545 Pass deployment target when linking with cc on Apple targets
When linking macOS targets with cc, pass the `-mmacosx-version-min=.`
option to specify the desired deployment target. Also, no longer pass
`-m32`/`-m64`, these are redundant since we already pass `-arch`.

When linking with cc on other Apple targets, always pass `-target`.
(We assume for these targets that cc => clang).
2024-09-09 13:57:17 +02:00
Mads Marquart 97df8fb7ec Fix default/minimum deployment target for Aarch64 simulator targets
The minimum that `rustc` encoded did not match the version in Clang, and
that meant that that when linking, we ended up bumping the version.

Specifically, this sets the correct deployment target of the following
simulator and Mac Catalyst targets:
- `aarch64-apple-ios-sim` from 10.0 to 14.0
- `aarch64-apple-tvos-sim` from 10.0 to 14.0
- `aarch64-apple-watchos-sim` from 5.0 to 7.0
- `aarch64-apple-ios-macabi` from 13.1 to 14.0

I have chosen to not document the simulator target versions in the
platform support docs, as it is fundamentally uninteresting; the normal
targets (e.g. `aarch64-apple-ios`, `aarch64-apple-tvos`) still have the
same deployment target as before, and that's what developers should
actually target.
2024-09-09 13:55:14 +02:00
Folkert de Vries 02378997ea bootstrap `naked_asm!` for `compiler-builtins`
in this commit, `naked_asm!` is an alias for `asm!` with one difference: `options(noreturn)` is always enabled by `naked_asm!`. That makes it future-compatible for when `naked_asm!` starts disallowing `options(noreturn)` later.
2024-09-09 12:47:40 +02:00
Jubilee fad44c424f
Rollup merge of #130107 - RalfJung:const-ptr-is-null, r=oli-obk
const: make ptr.is_null() stop execution on ambiguity

This seems better than saying `false` -- saying `false` is in fact actively unsound if `NonNull` then uses this to permit putting this pointer inside of it, but at runtime it turns out to be null.

Part of https://github.com/rust-lang/rust/issues/74939
Cc ```@rust-lang/wg-const-eval```
2024-09-09 00:17:51 -07:00
Jubilee fd938c7441
Rollup merge of #130068 - madsmtm:deployment-target-test, r=jieyouxu
Test codegen when setting deployment target

Test our codegen in different scenarios when setting the deployment target. There are many places here where this is still incorrect, these will be fixed in https://github.com/rust-lang/rust/pull/129342, https://github.com/rust-lang/rust/pull/129367 and https://github.com/rust-lang/rust/pull/129369. See https://github.com/rust-lang/rust/issues/129432 for the bigger picture.

Tested locally using:
```console
./x test tests/run-make/apple-deployment-target --target="aarch64-apple-darwin,aarch64-apple-ios,aarch64-apple-ios-macabi,aarch64-apple-ios-sim,aarch64-apple-tvos,aarch64-apple-tvos-sim,aarch64-apple-visionos,aarch64-apple-visionos-sim,aarch64-apple-watchos,aarch64-apple-watchos-sim,arm64_32-apple-watchos,armv7s-apple-ios,i386-apple-ios,x86_64-apple-darwin,x86_64-apple-ios,x86_64-apple-ios-macabi,x86_64-apple-tvos,x86_64-apple-watchos-sim,x86_64h-apple-darwin"
```

The only Apple targets that aren't tested by the above command are:
- `arm64e-apple-darwin`, failed to build, see https://github.com/rust-lang/cc-rs/issues/1205.
- `armv7k-apple-watchos`, failed to link, see https://github.com/rust-lang/rust/issues/130071.
- `arm64e-apple-ios`, failed to link, see https://github.com/rust-lang/rust/issues/130085.
- `i686-apple-darwin`, requires a bit of setup and an older machine, see [the docs](https://doc.rust-lang.org/nightly/rustc/platform-support/i686-apple-darwin.html).
- `i386-apple-ios` requires you to set `IPHONEOS_DEPLOYMENT_TARGET=10.0` for the test helpers to work, will be fixed by https://github.com/rust-lang/cc-rs/issues/1030.

But all of this is as it was before this PR.

Fixes https://github.com/rust-lang/rust/issues/47825, since we now have a test that compiles a `dylib` for `aarch64-apple-ios`.

Split out from https://github.com/rust-lang/rust/pull/129342, see that for a little bit of the review that this has gone through already.

r? petrochenkov

```@rustbot``` label O-apple
2024-09-09 00:17:49 -07:00
Jubilee 4cfb1c3154
Rollup merge of #128667 - its-the-shrimp:rustdoc_json_types_rename, r=aDotInTheVoid
rustdoc: normalise type/field names

Updates #100961

- `Import` -> `Use`, to better reflect the terminology of Rust & its syntax
- `TypeBinding` -> `AssocItemConstraint`, to sync up with `clean`
- `FnDecl` -> `FunctionSignature`, because that's what it is
- `Header` -> `FunctionHeader`, because `Header` is a very word that's very heavily loaded with different meanings
- `ItemEnum::AssocType`: `default` -> `type`, because those items appear in `impl` blocks as well, where they're _not_ the "default"
- `ItemEnum::AssocConst`: `default` -> `value`, see the previous point
- `ForeignType` -> `ExternType`, because "foreign" is not the right word there
- boolean fields' names made to consistently be a phrase that can be a yes/no answer, e.g. `async` -> `is_async`

The docs of `ItemEnum::AssocType::type_` & of `ItemEnum::AssocConst::value` are also updated to be up to date with the clarification of the name of the fields
2024-09-09 00:17:47 -07:00
Jubilee 2cce01ee62
Rollup merge of #128345 - sthibaul:hurd-amd64, r=Urgau
added support for GNU/Hurd on x86_64
2024-09-09 00:17:46 -07:00
Jubilee 1ea466bdce
Rollup merge of #119229 - mati865:update-mingw-toolchain, r=jieyouxu,petrochenkov
Update mingw-w64 + GNU toolchain

The list of packaged tools and their versions is available at: https://github.com/niXman/mingw-builds-binaries/releases/tag/14.1.0-rt_v12-rev0

Fixes: https://github.com/rust-lang/rust/issues/112368
2024-09-09 00:17:46 -07:00
Gurinder Singh 0f8efb3b5c Fix ICE caused by missing span in a region error 2024-09-09 12:27:36 +05:30
Samuel Thibault 7626015848 added support for GNU/Hurd on x86_64 2024-09-08 23:37:07 +02:00
Ralf Jung 7a3a317618 remove const_slice_index annotations, it never had a feature gate anyway 2024-09-08 23:08:43 +02:00
Ralf Jung 11d51aae86 const: make ptr.is_null() stop execution on ambiguity 2024-09-08 19:07:46 +02:00
bors 6d05f12170 Auto merge of #129346 - nnethercote:fix-double-handling-in-collect_tokens, r=petrochenkov
Fix double handling in `collect_tokens`

Double handling of AST nodes can occur in `collect_tokens`. This is when an inner call to `collect_tokens` produces an AST node, and then an outer call to `collect_tokens` produces the same AST node. This can happen in a few places, e.g. expression statements where the statement delegates `HasTokens` and `HasAttrs` to the expression. It will also happen more after #124141.

This PR fixes some double handling cases that cause problems, including #129166.

r? `@petrochenkov`
2024-09-08 05:35:23 +00:00
bors 7f4b270aa4 Auto merge of #129313 - RalfJung:coroutine-niches, r=compiler-errors
Supress niches in coroutines to avoid aliasing violations

As mentioned [here](https://github.com/rust-lang/rust/issues/63818#issuecomment-2264915918), using niches in fields of coroutines that are referenced by other fields is unsound: the discriminant accesses violate the aliasing requirements of the reference pointing to the relevant field. This issue causes [Miri errors in practice](https://github.com/rust-lang/miri/issues/3780).

The "obvious" fix for this is to suppress niches in coroutines. That's what this PR does. However, we have several tests explicitly ensuring that we *do* use niches in coroutines. So I see two options:
- We guard this behavior behind a `-Z` flag (that Miri will set by default). There is no known case of these aliasing violations causing miscompilations. But absence of evidence is not evidence of absence...
- (What this PR does right now.) We temporarily adjust the coroutine layout logic and the associated tests until the proper fix lands. The "proper fix" here is to wrap fields that other fields can point to in [`UnsafePinned`](https://github.com/rust-lang/rust/issues/125735) and make `UnsafePinned` suppress niches; that would then still permit using niches of *other* fields (those that never get borrowed). However, I know that coroutine sizes are already a problem, so I am not sure if this temporary size regression is acceptable.

`@compiler-errors` any opinion? Also who else should be Cc'd here?
2024-09-08 03:11:12 +00:00
EtomicBomb 548b6e197d add tests for behavior in rfc#3662
* Adds tests for the behavior from rfc#3662 in `tests/rustdoc/`
2024-09-07 19:02:22 -04:00
EtomicBomb 2e1cba6415 rfc#3662 changes under unstable flags
* All new functionality is under unstable options
* Adds `--merge=shared|none|finalize` flags
* Adds `--parts-out-dir=<crate specific directory>` for `--merge=none`
to write cross-crate info file for a single crate
* Adds `--include-parts-dir=<previously specified directory>` for
`--merge=finalize` to write cross-crate info files
* update tests/run-make/rustdoc-default-output/rmake.rs golden
2024-09-07 18:59:01 -04:00
Matthias Krüger 04b4523efc
Rollup merge of #130009 - notriddle:notriddle/trailing-arrow, r=lolbinarycat,GuillaumeGomez
rustdoc-search: allow trailing `Foo ->` arg search

Fixes #129710
2024-09-07 23:30:14 +02:00
Matthias Krüger a88b1af7c0
Rollup merge of #129869 - cyrgani:master, r=Mark-Simulacrum
add a few more crashtests

Added them for #123629, #127033 and #129372.
2024-09-07 23:30:13 +02:00
Matthias Krüger 7b7f2f7f74
Rollup merge of #129847 - compiler-errors:async-cycle, r=davidtwco
Do not call query to compute coroutine layout for synthetic body of async closure

There is code in the MIR validator that attempts to prevent query cycles when inlining a coroutine into itself, and will use the coroutine layout directly from the body when it detects that's the same coroutine as the one that's being validated. After #128506, this logic didn't take into account the fact that the coroutine def id will differ if it's the "by-move body" of an async closure. This PR implements that.

Fixes #129811
2024-09-07 23:30:13 +02:00
Matthias Krüger 37523d2a59
Rollup merge of #129677 - compiler-errors:by-move-body-err, r=cjgillot
Don't build by-move body when async closure is tainted

Fixes #129676

See explanation in the ui test.
2024-09-07 23:30:12 +02:00
Matthias Krüger 3b2139bdb1
Rollup merge of #129555 - RalfJung:const_float_bits_conv, r=dtolnay
stabilize const_float_bits_conv

This stabilizes `const_float_bits_conv`, and thus fixes https://github.com/rust-lang/rust/issues/72447. With https://github.com/rust-lang/rust/pull/128596 having landed, this is entirely a libs-only question now.

```rust
impl f32 {
    pub const fn to_bits(self) -> u32;
    pub const fn from_bits(v: u32) -> Self;
    pub const fn to_be_bytes(self) -> [u8; 4];
    pub const fn to_le_bytes(self) -> [u8; 4]
    pub const fn to_ne_bytes(self) -> [u8; 4];
    pub const fn from_be_bytes(bytes: [u8; 4]) -> Self;
    pub const fn from_le_bytes(bytes: [u8; 4]) -> Self;
    pub const fn from_ne_bytes(bytes: [u8; 4]) -> Self;
}

impl f64 {
    pub const fn to_bits(self) -> u64;
    pub const fn from_bits(v: u64) -> Self;
    pub const fn to_be_bytes(self) -> [u8; 8];
    pub const fn to_le_bytes(self) -> [u8; 8]
    pub const fn to_ne_bytes(self) -> [u8; 8];
    pub const fn from_be_bytes(bytes: [u8; 8]) -> Self;
    pub const fn from_le_bytes(bytes: [u8; 8]) -> Self;
    pub const fn from_ne_bytes(bytes: [u8; 8]) -> Self;
}
````

Cc `@rust-lang/wg-const-eval` `@rust-lang/libs-api`
2024-09-07 23:30:11 +02:00
Matthias Krüger ccf3f6e59d
Rollup merge of #126452 - compiler-errors:raw-lifetimes, r=spastorino
Implement raw lifetimes and labels (`'r#ident`)

This PR does two things:
1. Reserve lifetime prefixes, e.g. `'prefix#lt` in edition 2021.
2. Implements raw lifetimes, e.g. `'r#async` in edition 2021.

This PR additionally extends the `keyword_idents_2024` lint to also check lifetimes.

cc `@traviscross`
r? parser
2024-09-07 23:30:10 +02:00
bors ec867f03bc Auto merge of #126161 - Bryanskiy:delegation-generics-4, r=petrochenkov
Delegation: support generics in associated delegation items

This is a continuation of https://github.com/rust-lang/rust/pull/125929.

[design](https://github.com/Bryanskiy/posts/blob/master/delegation%20in%20generic%20contexts.md)

Generic parameters inheritance was implemented in all contexts. Generic arguments are not yet supported.

r? `@petrochenkov`
2024-09-07 18:12:05 +00:00
Tim (Theemathas) Chirananthavat 79b87c57cb Bless tests due to new method suggestions. 2024-09-07 21:06:49 +07:00
Mads Marquart c788dcc674 Test codegen when setting deployment target 2024-09-07 14:06:55 +02:00
Michael Goulet bce7c4b70e Don't build by-move body when async closure is tainted 2024-09-07 07:50:44 -04:00
Michael Goulet 29f31c58e9 Don't call fn_arg_names for non-fn in resolver 2024-09-07 07:38:22 -04:00
Michael Goulet b09b7da010
Rollup merge of #130054 - cuishuang:master, r=chenyukang
Add missing quotation marks
2024-09-07 14:21:23 +03:00
Michael Goulet bc2244f027
Rollup merge of #129940 - liushuyu:s390x-target-features, r=RalfJung
s390x: Fix a regression related to backchain feature

In #127506, we introduced a new IBM Z-specific target feature, `backchain`.

This particular `target-feature` was available as a function-level attribute in LLVM 17 and below, so some hacks were used to avoid blowing up LLVM when querying the supported LLVM features.

This led to an unfortunate regression where `cfg!(target-feature = "backchain")` will always return true.

This pull request aims to fix this issue, and a test has been introduced to ensure it will never happen again.

Fixes #129927.

r? `@RalfJung`
2024-09-07 14:21:22 +03:00
Michael Goulet d6a42983e5
Rollup merge of #129899 - veera-sivarajan:fix-97793-pr-final, r=chenyukang
Add Suggestions for Misspelled Keywords

Fixes #97793

This PR detects misspelled keywords using two heuristics:

1. Lowercasing the unexpected identifier.
2. Using edit distance to find a keyword similar to the unexpected identifier.

However, it does not detect each and every misspelled keyword to
minimize false positives and ambiguities. More details about the
implementation can be found in the comments.
2024-09-07 14:21:22 +03:00
Michael Goulet 6dd07e4e26
Rollup merge of #129891 - nikic:naked-no-san, r=jackh726
Do not request sanitizers for naked functions

Naked functions can only contain inline asm, so any instrumentation inserted by sanitizers is illegal. Don't request it.

Fixes https://github.com/rust-lang/rust/issues/129224.
2024-09-07 14:21:21 +03:00
Michael Goulet 41a20dcb87
Rollup merge of #129840 - GrigorenkoPV:elided-named-lifetimes-suggestion, r=cjgillot
Implement suggestions for `elided_named_lifetimes`

A follow-up to #129207, as per https://github.com/rust-lang/rust/pull/129207#issuecomment-2308992849.

r? cjgillot

I will probably squash this a bit, but later.

`@rustbot` label +A-lint
2024-09-07 14:21:20 +03:00
Michael Goulet adcee23a95
Rollup merge of #129468 - Rajveer100:hack-to-avoid-function-merging, r=Mark-Simulacrum
[testsuite][cleanup] Remove all usages of `dont_merge` hack to avoid function merging

Resolves #129438

The `-Zmerge-functions=disabled` compile flag exists for this purpose.
2024-09-07 14:21:19 +03:00
Folkert de Vries 46115fd6d3 fix ICE in CMSE type validation 2024-09-07 10:53:59 +02:00
Veera 14e86eb7d9 Add Suggestions for Misspelled Keywords
This PR detects misspelled keywords using two heuristics:

1. Lowercasing the unexpected identifier.
2. Using edit distance to find a keyword similar to the unexpected identifier.

However, it does not detect each and every misspelled keyword to
minimize false positives and ambiguities. More details about the
implementation can be found in the comments.
2024-09-06 23:07:45 -04:00
Camille GILLOT 6dfc4033be Do not ICE on expect(warnings). 2024-09-07 01:34:59 +00:00
cuishuang be10d56039 Add missing quotation marks
Signed-off-by: cuishuang <imcusg@gmail.com>
2024-09-07 09:23:28 +08:00
Kyle Huey 7ed9f945a2 Don't leave debug locations for constants sitting on the builder indefinitely.
Because constants are currently emitted *before* the prologue, leaving the
debug location on the IRBuilder spills onto other instructions in the prologue
and messes up both line numbers as well as the point LLVM chooses to be the
prologue end.

Example LLVM IR (irrelevant IR elided):
Before:

define internal { i64, i64 } @_ZN3tmp3Foo18var_return_opt_try17he02116165b0fc08cE(ptr align 8 %self) !dbg !347 {
start:
  %self.dbg.spill = alloca [8 x i8], align 8
  %_0 = alloca [16 x i8], align 8
  %residual.dbg.spill = alloca [0 x i8], align 1
    #dbg_declare(ptr %residual.dbg.spill, !353, !DIExpression(), !357)
  store ptr %self, ptr %self.dbg.spill, align 8, !dbg !357
    #dbg_declare(ptr %self.dbg.spill, !350, !DIExpression(), !358)

After:

define internal { i64, i64 } @_ZN3tmp3Foo18var_return_opt_try17h00b17d08874ddd90E(ptr align 8 %self) !dbg !347 {
start:
  %self.dbg.spill = alloca [8 x i8], align 8
  %_0 = alloca [16 x i8], align 8
  %residual.dbg.spill = alloca [0 x i8], align 1
    #dbg_declare(ptr %residual.dbg.spill, !353, !DIExpression(), !357)
  store ptr %self, ptr %self.dbg.spill, align 8
    #dbg_declare(ptr %self.dbg.spill, !350, !DIExpression(), !358)

Note in particular how !357 from %residual.dbg.spill's dbg_declare no longer
falls through onto the store to %self.dbg.spill. This fixes argument values
at entry when the constant is a ZST (e.g. <Option as Try>::Residual). This
fixes #130003 (but note that it does *not* fix issues with argument values and
non-ZST constants, which emit their own stores that have debug info on them,
like #128945).
2024-09-06 23:12:18 +00:00
Camille GILLOT 94f8347bae Check AttrId for expectations. 2024-09-06 20:51:06 +00:00
Michael Goulet 5054e8cba8 Lint against keyword lifetimes in keyword_idents 2024-09-06 10:32:48 -04:00
Michael Goulet afa24f0180 Add some more tests 2024-09-06 10:32:48 -04:00
Michael Goulet 9aaf873396 Reserve prefix lifetimes too 2024-09-06 10:32:48 -04:00
Pavel Grigorenko 9e2d264fa2 Hack around a conflict with `clippy::needless_lifetimes` 2024-09-06 17:06:35 +03:00
bors 17b322fa69 Auto merge of #121848 - lcnr:stabilize-next-solver, r=compiler-errors
stabilize `-Znext-solver=coherence`

r? `@compiler-errors`

---

This PR stabilizes the use of the next generation trait solver in coherence checking by enabling `-Znext-solver=coherence` by default. More specifically its use in the *implicit negative overlap check*. The tracking issue for this is https://github.com/rust-lang/rust/issues/114862. Closes #114862.

## Background

### The next generation trait solver

The new solver lives in [`rustc_trait_selection::solve`](https://github.com/rust-lang/rust/blob/master/compiler/rustc_trait_selection/src/solve/mod.rs) and is intended to replace the existing *evaluate*, *fulfill*, and *project* implementation. It also has a wider impact on the rest of the type system, for example by changing our approach to handling associated types.

For a more detailed explanation of the new trait solver, see the [rustc-dev-guide](https://rustc-dev-guide.rust-lang.org/solve/trait-solving.html). This does not stabilize the current behavior of the new trait solver, only the behavior impacting the implicit negative overlap check. There are many areas in the new solver which are not yet finalized. We are confident that their final design will not conflict with the user-facing behavior observable via coherence. More on that further down.

Please check out [the chapter](https://rustc-dev-guide.rust-lang.org/solve/significant-changes.html) summarizing the most significant changes between the existing and new implementations.

### Coherence and the implicit negative overlap check

Coherence checking detects any overlapping impls. Overlapping trait impls always error while overlapping inherent impls result in an error if they have methods with the same name. Coherence also results in an error if any other impls could exist, even if they are currently unknown. This affects impls which may get added to upstream crates in a backwards compatible way and impls from downstream crates.

Coherence failing to detect overlap is generally considered to be unsound, even if it is difficult to actually get runtime UB this way. It is quite easy to get ICEs due to bugs in coherence.

It currently consists of two checks:

The [orphan check] validates that impls do not overlap with other impls we do not know about: either because they may be defined in a sibling crate, or because an upstream crate is allowed to add it without being considered a breaking change.

The [overlap check] validates that impls do not overlap with other impls we know about. This is done as follows:
- Instantiate the generic parameters of both impls with inference variables
- Equate the `TraitRef`s of both impls. If it fails there is no overlap.
- [implicit negative]: Check whether any of the instantiated `where`-bounds of one of the impls definitely do not hold when using the constraints from the previous step. If a `where`-bound does not hold, there is no overlap.
- *explicit negative (still unstable, ignored going forward)*: Check whether the any negated `where`-bounds can be proven, e.g. a `&mut u32: Clone` bound definitely does not hold as an explicit `impl<T> !Clone for &mut T` exists.

The overlap check has to *prove that unifying the impls does not succeed*. This means that **incorrectly getting a type error during coherence is unsound** as it would allow impls to overlap: coherence has to be *complete*.

Completeness means that we never incorrectly error. This means that during coherence we must only add inference constraints if they are definitely necessary. During ordinary type checking [this does not hold](https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=01d93b592bd9036ac96071cbf1d624a9), so the trait solver has to behave differently, depending on whether we're in coherence or not.

The implicit negative check only considers goals to "definitely not hold" if they could not be implemented downstream, by a sibling, or upstream in a backwards compatible way. If the goal is is "unknowable" as it may get added in another crate, we add an ambiguous candidate: [source](bea5bebf3d/compiler/rustc_trait_selection/src/solve/assembly/mod.rs (L858-L883)).

[orphan check]: fd80c02c16/compiler/rustc_trait_selection/src/traits/coherence.rs (L566-L579)
[overlap check]: fd80c02c16/compiler/rustc_trait_selection/src/traits/coherence.rs (L92-L98)
[implicit negative]: fd80c02c16/compiler/rustc_trait_selection/src/traits/coherence.rs (L223-L281)

## Motivation

Replacing the existing solver in coherence fixes soundness bugs by removing sources of incompleteness in the type system. The new solver separately strengthens coherence, resulting in more impls being disjoint and passing the coherence check. The concrete changes will be elaborated further down. We believe the stabilization to reduce the likelihood of future bugs in coherence as the new implementation is easier to understand and reason about.

It allows us to remove the support for coherence and implicit-negative reasoning in the old solver, allowing us to remove some code and simplifying the old trait solver. We will only remove the old solver support once this stabilization has reached stable to make sure we're able to quickly revert in case any unexpected issues are detected before then.

Stabilizing the use of the next-generation trait solver expresses our confidence that its current behavior is intended and our work towards enabling its use everywhere will not require any breaking changes to the areas used by coherence checking. We are also confident that we will be able to replace the existing solver everywhere, as maintaining two separate systems adds a significant maintainance burden.

## User-facing impact and reasoning

### Breakage due to improved handling of associated types

The new solver fixes multiple issues related to associated types. As these issues caused coherence to consider more types distinct, fixing them results in more overlap errors. This is therefore a breaking change.

#### Structurally relating aliases containing bound vars

Fixes https://github.com/rust-lang/rust/issues/102048. In the existing solver relating ambiguous projections containing bound variables is structural. This is *incomplete* and allows overlapping impls. These was mostly not exploitable as the same issue also caused impls to not apply when trying to use them. The new solver defers alias-relating to a nested goal, fixing this issue:
```rust
// revisions: current next
//[next] compile-flags: -Znext-solver=coherence
trait Trait {}

trait Project {
    type Assoc<'a>;
}

impl Project for u32 {
    type Assoc<'a> = &'a u32;
}

// Eagerly normalizing `<?infer as Project>::Assoc<'a>` is ambiguous,
// so the old solver ended up structurally relating
//
//     (?infer, for<'a> fn(<?infer as Project>::Assoc<'a>))
//
// with
//
//     ((u32, fn(&'a u32)))
//
// Equating `&'a u32` with `<u32 as Project>::Assoc<'a>` failed, even
// though these types are equal modulo normalization.
impl<T: Project> Trait for (T, for<'a> fn(<T as Project>::Assoc<'a>)) {}

impl<'a> Trait for (u32, fn(&'a u32)) {}
//[next]~^ ERROR conflicting implementations of trait `Trait` for type `(u32, for<'a> fn(&'a u32))`
```

A crater run did not discover any breakage due to this change.

#### Unknowable candidates for higher ranked trait goals

This avoids an unsoundness by attempting to normalize in `trait_ref_is_knowable`, fixing https://github.com/rust-lang/rust/issues/114061. This is a side-effect of supporting lazy normalization, as that forces us to attempt to normalize when checking whether a `TraitRef` is knowable: [source](47dd709bed/compiler/rustc_trait_selection/src/solve/assembly/mod.rs (L754-L764)).

```rust
// revisions: current next
//[next] compile-flags: -Znext-solver=coherence
trait IsUnit {}
impl IsUnit for () {}

pub trait WithAssoc<'a> {
    type Assoc;
}

// We considered `for<'a> <T as WithAssoc<'a>>::Assoc: IsUnit`
// to be knowable, even though the projection is ambiguous.
pub trait Trait {}
impl<T> Trait for T
where
    T: 'static,
    for<'a> T: WithAssoc<'a>,
    for<'a> <T as WithAssoc<'a>>::Assoc: IsUnit,
{
}
impl<T> Trait for Box<T> {}
//[next]~^ ERROR conflicting implementations of trait `Trait`
```
The two impls of `Trait` overlap given the following downstream crate:
```rust
use dep::*;
struct Local;
impl WithAssoc<'_> for Box<Local> {
    type Assoc = ();
}
```

There a similar coherence unsoundness caused by our handling of aliases which is fixed separately in https://github.com/rust-lang/rust/pull/117164.

This change breaks the [`derive-visitor`](https://crates.io/crates/derive-visitor) crate. I have opened an issue in that repo: nikis05/derive-visitor#16.

### Evaluating goals to a fixpoint and applying inference constraints

In the old implementation of the implicit-negative check, each obligation is [checked separately without applying its inference constraints](bea5bebf3d/compiler/rustc_trait_selection/src/traits/coherence.rs (L323-L338)). The new solver instead [uses a `FulfillmentCtxt`](bea5bebf3d/compiler/rustc_trait_selection/src/traits/coherence.rs (L315-L321)) for this, which evaluates all obligations in a loop until there's no further inference progress.

This is necessary for backwards compatibility as we do not eagerly normalize with the new solver, resulting in constraints from normalization to only get applied by evaluating a separate obligation. This also allows more code to compile:
```rust
// revisions: current next
//[next] compile-flags: -Znext-solver=coherence
trait Mirror {
    type Assoc;
}
impl<T> Mirror for T {
    type Assoc = T;
}

trait Foo {}
trait Bar {}

// The self type starts out as `?0` but is constrained to `()`
// due to the where-clause below. Because `(): Bar` is known to
// not hold, we can prove the impls disjoint.
impl<T> Foo for T where (): Mirror<Assoc = T> {}
//[current]~^ ERROR conflicting implementations of trait `Foo` for type `()`
impl<T> Foo for T where T: Bar {}

fn main() {}
```
The old solver does not run nested goals to a fixpoint in evaluation. The new solver does do so, strengthening inference and improving the overlap check:
```rust
// revisions: current next
//[next] compile-flags: -Znext-solver=coherence
trait Foo {}
impl<T> Foo for (u8, T, T) {}
trait NotU8 {}
trait Bar {}
impl<T, U: NotU8> Bar for (T, T, U) {}

trait NeedsFixpoint {}
impl<T: Foo + Bar> NeedsFixpoint for T {}
impl NeedsFixpoint for (u8, u8, u8) {}

trait Overlap {}
impl<T: NeedsFixpoint> Overlap for T {}
impl<T, U: NotU8, V> Overlap for (T, U, V) {}
//[current]~^ ERROR conflicting implementations of trait `Foo`
```

### Breakage due to removal of incomplete candidate preference

Fixes #107887. In the old solver we incompletely prefer the builtin trait object impl over user defined impls. This can break inference guidance, inferring `?x` in `dyn Trait<u32>: Trait<?x>` to `u32`, even if an explicit impl of `Trait<u64>` also exists.

This caused coherence to incorrectly allow overlapping impls, resulting in ICEs and a theoretical unsoundness. See https://github.com/rust-lang/rust/issues/107887#issuecomment-1997261676. This compiles on stable but results in an overlap error with `-Znext-solver=coherence`:

```rust
// revisions: current next
//[next] compile-flags: -Znext-solver=coherence
struct W<T: ?Sized>(*const T);

trait Trait<T: ?Sized> {
    type Assoc;
}

// This would trigger the check for overlap between automatic and custom impl.
// They actually don't overlap so an impl like this should remain possible
// forever.
//
// impl Trait<u64> for dyn Trait<u32> {}
trait Indirect {}
impl Indirect for dyn Trait<u32, Assoc = ()> {}
impl<T: Indirect + ?Sized> Trait<u64> for T {
    type Assoc = ();
}

// Incomplete impl where `dyn Trait<u32>: Trait<_>` does not hold, but
// `dyn Trait<u32>: Trait<u64>` does.
trait EvaluateHack<U: ?Sized> {}
impl<T: ?Sized, U: ?Sized> EvaluateHack<W<U>> for T
where
    T: Trait<U, Assoc = ()>, // incompletely constrains `_` to `u32`
    U: IsU64,
    T: Trait<U, Assoc = ()>, // incompletely constrains `_` to `u32`
{
}

trait IsU64 {}
impl IsU64 for u64 {}

trait Overlap<U: ?Sized> {
    type Assoc: Default;
}
impl<T: ?Sized + EvaluateHack<W<U>>, U: ?Sized> Overlap<U> for T {
    type Assoc = Box<u32>;
}
impl<U: ?Sized> Overlap<U> for dyn Trait<u32, Assoc = ()> {
//[next]~^ ERROR conflicting implementations of trait `Overlap<_>`
    type Assoc = usize;
}
```

### Considering region outlives bounds in the `leak_check`

For details on the `leak_check`, see the FCP proposal in #119820.[^leak_check]

[^leak_check]: which should get moved to the dev-guide once that PR lands :3

In both coherence and during candidate selection, the `leak_check` relies on the region constraints added in `evaluate`. It therefore currently does not register outlives obligations: [source](ccb1415eac/compiler/rustc_trait_selection/src/traits/select/mod.rs (L792-L810)). This was likely done as a performance optimization without considering its impact on the `leak_check`. This is the case as in the old solver, *evaluatation* and *fulfillment* are split, with evaluation being responsible for candidate selection and fulfillment actually registering all the constraints.

This split does not exist with the new solver. The `leak_check` can therefore eagerly detect errors caused by region outlives obligations. This improves both coherence itself and candidate selection:

```rust
// revisions: current next
//[next] compile-flags: -Znext-solver=coherence
trait LeakErr<'a, 'b> {}
// Using this impl adds an `'b: 'a` bound which results
// in a higher-ranked region error. This bound has been
// previously ignored but is now considered.
impl<'a, 'b: 'a> LeakErr<'a, 'b> for () {}

trait NoOverlapDir<'a> {}
impl<'a, T: for<'b> LeakErr<'a, 'b>> NoOverlapDir<'a> for T {}
impl<'a> NoOverlapDir<'a> for () {}
//[current]~^ ERROR conflicting implementations of trait `NoOverlapDir<'_>`

// --------------------------------------

// necessary to avoid coherence unknowable candidates
struct W<T>(T);

trait GuidesSelection<'a, U> {}
impl<'a, T: for<'b> LeakErr<'a, 'b>> GuidesSelection<'a, W<u32>> for T {}
impl<'a, T> GuidesSelection<'a, W<u8>> for T {}

trait NotImplementedByU8 {}
trait NoOverlapInd<'a, U> {}
impl<'a, T: GuidesSelection<'a, W<U>>, U> NoOverlapInd<'a, U> for T {}
impl<'a, U: NotImplementedByU8> NoOverlapInd<'a, U> for () {}
//[current]~^ conflicting implementations of trait `NoOverlapInd<'_, _>`
```

### Removal of `fn match_fresh_trait_refs`

The old solver tries to [eagerly detect unbounded recursion](b14fd2359f/compiler/rustc_trait_selection/src/traits/select/mod.rs (L1196-L1211)), forcing the affected goals to be ambiguous. This check is only an approximation and has not been added to the new solver.

The check is not necessary in the new solver and it would be problematic for caching. As it depends on all goals currently on the stack, using a global cache entry would have to always make sure that doing so does not circumvent this check.

This changes some goals to error - or succeed - instead of failing with ambiguity. This allows more code to compile:

```rust
// revisions: current next
//[next] compile-flags: -Znext-solver=coherence

// Need to use this local wrapper for the impls to be fully
// knowable as unknowable candidate result in ambiguity.
struct Local<T>(T);

trait Trait<U> {}
// This impl does not hold, but is ambiguous in the old
// solver due to its overflow approximation.
impl<U> Trait<U> for Local<u32> where Local<u16>: Trait<U> {}
// This impl holds.
impl Trait<Local<()>> for Local<u8> {}

// In the old solver, `Local<?t>: Trait<Local<?u>>` is ambiguous,
// resulting in `Local<?u>: NoImpl`, also being ambiguous.
//
// In the new solver the first impl does not apply, constraining
// `?u` to `Local<()>`, causing `Local<()>: NoImpl` to error.
trait Indirect<T> {}
impl<T, U> Indirect<U> for T
where
    T: Trait<U>,
    U: NoImpl
{}

// Not implemented for `Local<()>`
trait NoImpl {}
impl NoImpl for Local<u8> {}
impl NoImpl for Local<u16> {}

// `Local<?t>: Indirect<Local<?u>>` cannot hold, so
// these impls do not overlap.
trait NoOverlap<U> {}
impl<T: Indirect<U>, U> NoOverlap<U> for T {}
impl<T, U> NoOverlap<Local<U>> for Local<T> {}
//~^ ERROR conflicting implementations of trait `NoOverlap<Local<_>>`
```

### Non-fatal overflow

The old solver immediately emits a fatal error when hitting the recursion limit. The new solver instead returns overflow. This both allows more code to compile and is results in performance and potential future compatability issues.

Non-fatal overflow is generally desirable. With fatal overflow, changing the order in which we evaluate nested goals easily causes breakage if we have goal which errors and one which overflows. It is also required to prevent breakage due to the removal of `fn match_fresh_trait_refs`, e.g. [in `typenum`](https://github.com/rust-lang/trait-system-refactor-initiative/issues/73).

#### Enabling more code to compile

In the below example, the old solver first tried to prove an overflowing goal, resulting in a fatal error. The new solver instead returns ambiguity due to overflow for that goal, causing the implicit negative overlap check to succeed as `Box<u32>: NotImplemented` does not hold.
```rust
// revisions: current next
//[next] compile-flags: -Znext-solver=coherence
//[current] ERROR overflow evaluating the requirement

trait Indirect<T> {}
impl<T: Overflow<()>> Indirect<T> for () {}

trait Overflow<U> {}
impl<T, U> Overflow<U> for Box<T>
where
    U: Indirect<Box<Box<T>>>,
{}

trait NotImplemented {}

trait Trait<U> {}
impl<T, U> Trait<U> for T
where
    // T: NotImplemented, // causes old solver to succeed
    U: Indirect<T>,
    T: NotImplemented,
{}

impl Trait<()> for Box<u32> {}
```

#### Avoiding hangs with non-fatal overflow

Simply returning ambiguity when reaching the recursion limit can very easily result in hangs, e.g.
```rust
trait Recur {}
impl<T, U> Recur for ((T, U), (U, T))
where
    (T, U): Recur,
    (U, T): Recur,
{}

trait NotImplemented {}
impl<T: NotImplemented> Recur for T {}
```
This can happen quite frequently as it's easy to have exponential blowup due to multiple nested goals at each step. As the trait solver is depth-first, this immediately caused a fatal overflow error in the old solver. In the new solver we have to handle the whole proof tree instead, which can very easily hang.

To avoid this we restrict the recursion depth after hitting the recursion limit for the first time. We also **ignore all inference constraints from goals resulting in overflow**. This is mostly backwards compatible as any overflow in the old solver resulted in a fatal error.

### sidenote about normalization

We return ambiguous nested goals of `NormalizesTo` goals to the caller and ignore their impact when computing the `Certainty` of the current goal. See the [normalization chapter](https://rustc-dev-guide.rust-lang.org/solve/normalization.html) for more details.This means we apply constraints resulting from other nested goals and from equating the impl header when normalizing, even if a nested goal results in overflow. This is necessary to avoid breaking the following example:
```rust
trait Trait {
    type Assoc;
}

struct W<T: ?Sized>(*mut T);
impl<T: ?Sized> Trait for W<W<T>>
where
    W<T>: Trait,
{
    type Assoc = ();
}

// `W<?t>: Trait<Assoc = u32>` does not hold as
// `Assoc` gets normalized to `()`. However, proving
// the where-bounds of the impl results in overflow.
//
// For this to continue to compile we must not discard
// constraints from normalizing associated types.
trait NoOverlap {}
impl<T: Trait<Assoc = u32>> NoOverlap for T {}
impl<T: ?Sized> NoOverlap for W<T> {}
```

#### Future compatability concerns

Non-fatal overflow results in some unfortunate future compatability concerns. Changing the approach to avoid more hangs by more strongly penalizing overflow can cause breakage as we either drop constraints or ignore candidates necessary to successfully compile. Weakening the overflow penalities instead allows more code to compile and strengthens inference while potentially causing more code to hang.

While the current approach is not perfect, we believe it to be good enough. We believe it to apply the necessary inference constraints to avoid breakage and expect there to not be any desirable patterns broken by our current penalities. Similarly we believe the current constraints to avoid most accidental hangs. Ignoring constraints of overflowing goals is especially useful, as it may allow major future optimizations to our overflow handling. See [this summary](https://hackmd.io/ATf4hN0NRY-w2LIVgeFsVg) and the linked documents in case you want to know more.

### changes to performance

In general, trait solving during coherence checking is not significant for performance. Enabling the next-generation trait solver in coherence does not impact our compile time benchmarks. We are still unable to compile the benchmark suite when fully enabling the new trait solver.

There are rare cases where the new solver has significantly worse performance due to non-fatal overflow, its reliance on fixpoint algorithms and the removal of the `fn match_fresh_trait_refs` approximation. We encountered such issues in [`typenum`](https://crates.io/crates/typenum) and believe it should be [pretty much as bad as it can get](https://github.com/rust-lang/trait-system-refactor-initiative/issues/73).

Due to an improved structure and far better caching, we believe that there is a lot of room for improvement and that the new solver will outperform the existing implementation in nearly all cases, sometimes significantly. We have not yet spent any time micro-optimizing the implementation and have many unimplemented major improvements, such as fast-paths for trivial goals.

TODO: get some rough results here and put them in a table

### Unstable features

#### Unsupported unstable features

The new solver currently does not support all unstable features, most notably `#![feature(generic_const_exprs)]`, `#![feature(associated_const_equality)]` and `#![feature(adt_const_params)]` are not yet fully supported in the new solver. We are confident that supporting them is possible, but did not consider this to be a priority. This stabilization introduces new ICE when using these features in impl headers.

#### fixes to `#![feature(specialization)]`

- fixes #105782
- fixes #118987

#### fixes to `#![feature(type_alias_impl_trait)]`

- fixes #119272
- https://github.com/rust-lang/rust/issues/105787#issuecomment-1750112388
- fixes #124207

## This does not stabilize the whole solver

While this stabilizes the use of the new solver in coherence checking, there are many parts of the solver which will remain fully unstable. We may still adapt these areas while working towards stabilizing the new solver everywhere. We are confident that we are able to do so without negatively impacting coherence.

### goals with a non-empty `ParamEnv`

Coherence always uses an empty environment. We therefore do not depend on the behavior of `AliasBound` and `ParamEnv` candidates. We only stabilizes the behavior of user-defined and builtin implementations of traits. There are still many open questions there.

### opaque types in the defining scope

The handling of opaque types - `impl Trait` - in both the new and old solver is still not fully figured out. Luckily this can be ignored for now. While opaque types are reachable during coherence checking by using `impl_trait_in_associated_types`, the behavior during coherence is separate and self-contained. The old and new solver fully agree here.

### normalization is hard

This stabilizes that we equate associated types involving bound variables using deferred-alias-equality. We also stop eagerly normalizing in coherence, which should not have any user-facing impact.

We do not stabilize the normalization behavior outside of coherence, e.g. we currently deeply normalize all types during writeback with the new solver. This may change going forward

### how to replace `select` from the old solver

We sometimes depend on getting a single `impl` for a given trait bound, e.g. when resolving a concrete method for codegen/CTFE. We do not depend on this during coherence, so the exact approach here can still be freely changed going forward.

## Acknowledgements

This work would not have been possible without `@compiler-errors.` He implemented large chunks of the solver himself but also and did a lot of testing and experimentation, eagerly discovering multiple issues which had a significant impact on our approach. `@BoxyUwU` has also done some amazing work on the solver. Thank you for the endless hours of discussion resulting in the current approach. Especially the way aliases are handled has gone through multiple revisions to get to its current state.

There were also many contributions from - and discussions with - other members of the community and the rest of `@rust-lang/types.` This solver builds upon previous improvements to the compiler, as well as lessons learned from `chalk` and `a-mir-formality`. Getting to this point  would not have been possible without that and I am incredibly thankful to everyone involved. See the [list of relevant PRs](https://github.com/rust-lang/rust/pulls?q=is%3Apr+is%3Amerged+label%3AWG-trait-system-refactor+-label%3Arollup+closed%3A%3C2024-03-22+).
2024-09-06 13:12:14 +00:00
Pavel Grigorenko 547db4a4b7 elided_named_lifetimes: manually implement `LintDiagnostic` 2024-09-06 15:47:52 +03:00
Pavel Grigorenko dcfc71310d elided_named_lifetimes: add suggestions 2024-09-06 15:47:52 +03:00
Nikita Popov 54ebb9d489 Do not request sanitizers for naked functions
Naked functions can only contain inline asm, so any instrumentation
inserted by sanitizers is illegal. Don't request it.

Fixes https://github.com/rust-lang/rust/issues/129224.
2024-09-06 14:11:13 +02:00
Urgau 7dd1be1d0d Also emit `missing_docs` lint with `--test` to fulfill expectations 2024-09-06 12:20:36 +02:00
Matthias Krüger 11d5614a74
Rollup merge of #130013 - jonathan-conder:await_coverage, r=Zalathar
coverage: Count await when the Future is immediately ready

Currently `await` is only counted towards coverage if the containing
function is suspended and resumed at least once. This is because it
expands to code which contains a branch on the discriminant of `Poll`.

By treating it like a branching macro (e.g. `assert!`), these
implementation details will be hidden from the coverage results.

I added a test to ensure the fix works in simple cases, but the heuristic of picking only the first await-related covspan might be unreliable. I plan on testing more thoroughly with a real codebase over the next couple of weeks.

closes #98712
2024-09-06 07:33:59 +02:00
Matthias Krüger e903b29dc3
Rollup merge of #129021 - compiler-errors:ptr-cast-outlives, r=lcnr
Check WF of source type's signature on fn pointer cast

This PR patches the implied bounds holes slightly for #129005, #25860.

Like most implied bounds related unsoundness fixes, this isn't complete w.r.t. higher-ranked function signatures, but I believe it implements a pretty good heuristic for now.

### What does this do?

This PR makes a partial patch for a soundness hole in a `FnDef` -> `FnPtr` "reifying" pointer cast where we were never checking that the signature we are casting *from* is actually well-formed. Because of this, and because `FnDef` doesn't require its signature to be well-formed (just its predicates must hold), we are essentially allowed to "cast away" implied bounds that are assumed within the body of the `FnDef`:

```
fn foo<'a, 'b, T>(_: &'a &'b (), v: &'b T) -> &'a T { v }

fn bad<'short, T>(x: &'short T) -> &'static T {
    let f: fn(_, &'short T) -> &'static T = foo;
    f(&&(), x)
}
```

In this example, subtyping ends up casting the `_` type (which should be `&'static &'short ()`) to some other type that no longer serves as a "witness" to the lifetime relationship `'short: 'static` which would otherwise be required for this call to be WF. This happens regardless of if `foo`'s lifetimes are early- or late-bound.

This PR implements two checks:
1. We check that the signature of the `FnDef` is well-formed *before* casting it. This ensures that there is at least one point in the MIR where we ensure that the `FnDef`'s implied bounds are actually satisfied by the caller.
2. Implements a special case where if we're casting from a higher-ranked `FnDef` to a non-higher-ranked, we instantiate the binder of the `FnDef` with *infer vars* and ensure that it is a supertype of the target of the cast.

The (2.) is necessary to validate that these pointer casts are valid for higher-ranked `FnDef`. Otherwise, the example above would still pass even if `help`'s `'a` lifetime were late-bound.

### Further work

The WF checks for function calls are scattered all over the MIR. We check the WF of args in call terminators, we check the WF of `FnDef` when we create a `const` operand referencing it, and we check the WF of the return type in #115538, to name a few.

One way to make this a bit cleaner is to simply extend #115538 to always check that the signature is WF for `FnDef` types. I may do this as a follow-up, but I wanted to keep this simple since this leads to some pretty bad NLL diagnostics regressions, and AFAICT this solution is *complete enough*.

### Crater triage

Done here: https://github.com/rust-lang/rust/pull/129021#issuecomment-2297702647

r? lcnr
2024-09-06 07:33:56 +02:00
Jonathan Conder 25d183057e coverage: Treat await similar to a macro
Currently `await` is only counted towards coverage if the containing
function is suspended and resumed at least once. This is because it
expands to code which contains a branch on the discriminant of `Poll`.

By treating it like a branching macro (e.g. `assert!`), these
implementation details will be hidden from the coverage results.
2024-09-06 17:01:59 +12:00
Jonathan Conder 3446ca535e coverage: Add test to codify existing behavior
Currently `await` is only counted towards coverage if the containing
function is suspended and resumed at least once. A future commit will
fix this and update the test to reflect the new behavior.
2024-09-06 16:50:23 +12:00
bors d678b81485 Auto merge of #129999 - matthiaskrgr:rollup-pzr9c8p, r=matthiaskrgr
Rollup of 11 pull requests

Successful merges:

 - #128919 (Add an internal lint that warns when accessing untracked data)
 - #129472 (fix ICE when `asm_const` and `const_refs_to_static` are combined)
 - #129653 (clarify that addr_of creates read-only pointers)
 - #129775 (bootstrap: Try to track down why `initial_libdir` sometimes fails)
 - #129939 (explain why Rvalue::Len still exists)
 - #129942 (copy rustc rustlib artifacts from ci-rustc)
 - #129943 (use the bootstrapped compiler for `test-float-parse` test)
 - #129944 (Add compat note for trait solver change)
 - #129947 (Add digit separators in `Duration` examples)
 - #129955 (Temporarily remove fmease from the review rotation)
 - #129957 (forward linker option to lint-docs)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-09-06 03:06:52 +00:00
Michael Howell 3699e939e8 rustdoc-search: allow trailing `Foo ->` arg search 2024-09-05 17:58:05 -07:00
bors 54fdef7799 Auto merge of #121614 - clubby789:no-expect, r=saethlin
Don't emit `expect`/`assume` in opt-level=0

LLVM does not make use of expect/assume calls in `opt-level=0`, so we can simplify IR by not emitting them in this case.
2024-09-06 00:42:58 +00:00
Matthias Krüger 3daa015f82
Rollup merge of #129472 - folkertdev:const-refs-to-static-asm-const, r=lcnr
fix ICE when `asm_const` and `const_refs_to_static` are combined

fixes https://github.com/rust-lang/rust/issues/129462
fixes #126896
fixes #124164

I think this is a case that was missed in the fix for https://github.com/rust-lang/rust/pull/125558, which inserts a type error in the case of an invalid (that is, non-integer) type being passed to an asm `const` operand.

I'm not 100% sure that `span_mirbug_and_err` is the right macro here, but it is used earlier with `builtin_deref` and seems to do the trick.

r? ``@lcnr``
2024-09-05 19:43:46 +02:00
Matthias Krüger 46f390f047
Rollup merge of #128919 - Nadrieril:lint-query-leaks, r=cjgillot
Add an internal lint that warns when accessing untracked data

Some methods access data that is not tracked by the query system and should be used with caution. As suggested in https://github.com/rust-lang/rust/pull/128815#issuecomment-2275488683, in this PR I propose a lint (modeled on the `potential_query_instability` lint) that warns when using some specially-annotatted functions.

I can't tell myself if this lint would be that useful, compared to renaming `Steal::is_stolen` to `is_stolen_untracked`. This would depend on whether there are other functions we'd want to lint like this. So far it seems they're called `*_untracked`, which may be clear enough.

r? ``@oli-obk``
2024-09-05 19:43:46 +02:00
Matthias Krüger fee6c0a683
Rollup merge of #129973 - jieyouxu:rework-rmake-stdio, r=Kobzol
run_make_support: rename `Command::stdin` to `stdin_buf` and add `std{in,out,err}` config helpers

Previously `Command::stdin` was actually just a stdin buffer helper, but
this is different from `std::process::Command::stdin`. This is
needlessly confusing, and blocks support to add `std{in,out,err}` config
helpers that tests may want to use to e.g. redirect to `/dev/ptmx`.
2024-09-05 18:58:57 +02:00
Matthias Krüger 9be97ae8e2
Rollup merge of #129796 - GuillaumeGomez:unify-code-examples, r=notriddle
Unify scraped examples with other code examples

Fixes #129763.

This first PR both fixes #129763 but also unifies buttons display for code examples:

![image](https://github.com/user-attachments/assets/c8475945-dcc3-4c25-8d7d-1659f85301c8)

You can test it [here](https://rustdoc.crud.net/imperio/unify-code-examples/doc/scrape_examples/fn.test.html) and [here](https://rustdoc.crud.net/imperio/unify-code-examples/doc/scrape_examples/fn.test_many.html).

I'm planning to send a follow-up to make the buttons generated in JS directly (or I can do it in this PR directly if you prefer).

cc ```@willcrichton```
r? ```@notriddle```
2024-09-05 18:58:56 +02:00
Matthias Krüger 11085aa73a
Rollup merge of #129706 - compiler-errors:scratch, r=estebank
Rename dump of coroutine by-move-body to be more consistent, fix ICE in dump_mir

First, we add a missing match for `DefKind::SyntheticCoroutineBody` in `dump_mir`. Fixes #129703. The second commit (directly below) serves as a test.

Second, we reorder the `dump_mir` in `coroutine_by_move_body_def_id` to be *after* we adjust the body source, and change the disambiguator so it reads more like any other MIR body. This also serves as a test for the ICE, since we're dumping the MIR of a body with `DefKind::SyntheticCoroutineBody`.

Third, we change the parenting of the synthetic MIR body to have the *coroutine-closure* (i.e. async closure) as its parent, so we don't have long strings of `{closure#0}-{closure#0}-{closure#0}`.

try-job: test-various
2024-09-05 18:58:55 +02:00
Matthias Krüger 6a23ee5595
Rollup merge of #129471 - GuillaumeGomez:sort-impl-associated-items, r=t-rustdoc-frontend
[rustdoc] Sort impl associated items by kinds and then by appearance

Following [this zulip discussion](https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/.22Freeze.22.20order.20of.20items.20in.20.28trait.29.20impls.3F), I implemented it.

This brings the following change: impl associated items will now be grouped by kind and will now be first sorted by kind and then by the order they are declared in the source code (like currently).

The kinds are sorted in the following order:
1. Constants
2. Types
3. Functions

The reason behind this order is that associated constants can be used in associated types (like length in arrays) and both associated types and associated constants can be used in associated functions. So if an associated item from the same impl is used, its definition will always be above where it's being used.

cc ``@camelid``
r? ``@notriddle``
2024-09-05 18:58:54 +02:00
arnaudgolfouse 13d56dc160 Use a `Vec` in `rustc_interface::Config::locale_resources`
This allows a third-party tool to injects its own resources,
when receiving the config via `rustc_driver::Callbacks::config`.
2024-09-05 16:49:38 +02:00
Bryanskiy 588dce1421 Delegation: support generics in associated delegation items 2024-09-05 16:04:50 +03:00
Michael Goulet 67804c57e7 Adjust tests 2024-09-05 06:37:38 -04:00
Michael Goulet e8472e84e3 Check unnormalized signature on pointer cast 2024-09-05 06:37:38 -04:00
Michael Goulet f8f4d50aa3 Don't worry about uncaptured contravariant lifetimes if they outlive a captured lifetime 2024-09-05 06:34:42 -04:00
Guillaume Gomez 238944c5d7 Add regression test for sidebar associated items 2024-09-05 12:16:59 +02:00
Guillaume Gomez 1884983001 Make impl associated constants sorted first 2024-09-05 12:15:15 +02:00
Guillaume Gomez f96aff95d5 Add regression test for impl associated items sorting 2024-09-05 12:13:59 +02:00
许杰友 Jieyou Xu (Joe) afed862b26 tests: use renamed `stdin_buf` 2024-09-05 08:43:38 +00:00
lcnr a138a92615 update test description 2024-09-05 07:57:17 +00:00
lcnr 69fdd1457d remove unnecessary revisions 2024-09-05 07:57:17 +00:00
lcnr d93e047c9f rebase and update fixed `crashes` 2024-09-05 07:57:17 +00:00
lcnr 1a893ac648 stabilize `-Znext-solver=coherence` 2024-09-05 07:57:16 +00:00
Matthias Krüger 08187c32c7
Rollup merge of #129664 - adetaylor:arbitrary-self-types-pointers-feature-gate, r=wesleywiser
Arbitrary self types v2: pointers feature gate.

The main `arbitrary_self_types` feature gate will shortly be reused for a new version of arbitrary self types which we are amending per [this RFC](https://github.com/rust-lang/rfcs/blob/master/text/3519-arbitrary-self-types-v2.md). The main amendments are:

* _do_ support `self` types which can't safely implement `Deref`
* do _not_ support generic `self` types
* do _not_ support raw pointers as `self` types.

This PR relates to the last of those bullet points: this strips pointer support from the current `arbitrary_self_types` feature. We expect this to cause some amount of breakage for crates using this unstable feature to allow raw pointer self types. If that's the case, we want to know about it, and we want crate authors to know of the upcoming changes.

For now, this can be resolved by adding the new
`arbitrary_self_types_pointers` feature to such crates. If we determine that use of raw pointers as self types is common, then we may maintain that as an unstable feature even if we come to stabilize the rest of the `arbitrary_self_types` support in future. If we don't hear that this PR is causing breakage, then perhaps we don't need it at all, even behind an unstable feature gate.

[Tracking issue](https://github.com/rust-lang/rust/issues/44874)

This is [step 4 of the plan outlined here](https://github.com/rust-lang/rust/issues/44874#issuecomment-2122179688)
2024-09-05 03:47:42 +02:00
Matthias Krüger 3775e6bd9f
Rollup merge of #127021 - thesummer:1-add-target-support-for-rtems-arm-xilinx-zedboard, r=tgross35
Add target support for RTEMS Arm

# `armv7-rtems-eabihf`

This PR adds a new target for the RTEMS RTOS. To get things started it focuses on Xilinx/AMD Zynq-based targets, but in theory it should also support other armv7-based board support packages in the future.
Given that RTEMS has support for many POSIX functions it is mostly enabling corresponding unix features for the new target.
I also previously started a PR in libc (https://github.com/rust-lang/libc/pull/3561) to add the needed OS specific C-bindings and was told that a PR in this repo is needed first. I will update the PR to the newest version after approval here.
I will probably also need to change one line in the backtrace repo.

Current status is that I could compile rustc for the new target locally (with the updated libc and backtrace) and could compile binaries, link, and execute a simple "Hello World" RTEMS application for the target hardware.

> A proposed target or target-specific patch that substantially changes code shared with other targets (not just target-specific code) must be reviewed and approved by the appropriate team for that shared code before acceptance.

There should be no breaking changes for existing targets. Main changes are adding corresponding `cfg` switches for the RTEMS OS and adding the C binding in libc.

# Tier 3 target policy

> - A tier 3 target must have a designated developer or developers (the "target maintainers") on record to be CCed when issues arise regarding the target. (The mechanism to track and CC such developers may evolve over time.)

I will do the maintenance (for now) further members of the RTEMS community will most likely join once the first steps have been done.

> - Targets must use naming consistent with any existing targets; for instance, a target for the same CPU or OS as an existing Rust target should use the same name for that CPU or OS. Targets should normally use the same names and naming conventions as used elsewhere in the broader ecosystem beyond Rust (such as in other toolchains), unless they have a very good reason to diverge. Changing the name of a target can be highly disruptive, especially once the target reaches a higher tier, so getting the name right is important even for a tier 3 target.
>     - Target names should not introduce undue confusion or ambiguity unless absolutely necessary to maintain ecosystem compatibility. For example, if the name of the target makes people extremely likely to form incorrect beliefs about what it targets, the name should be changed or augmented to disambiguate it.
>     - If possible, use only letters, numbers, dashes and underscores for the name. Periods (`.`) are known to cause issues in Cargo.

The proposed triple is `armv7-rtems-eabihf`

> - Tier 3 targets may have unusual requirements to build or use, but must not create legal issues or impose onerous legal terms for the Rust project or for Rust developers or users.
>     - The target must not introduce license incompatibilities.
>     - Anything added to the Rust repository must be under the standard Rust license (`MIT OR Apache-2.0`).
>     - The target must not cause the Rust tools or libraries built for any other host (even when supporting cross-compilation to the target) to depend on any new dependency less permissive than the Rust licensing policy. This applies whether the dependency is a Rust crate that would require adding new license exceptions (as specified by the `tidy` tool in the rust-lang/rust repository), or whether the dependency is a native library or binary. In other words, the introduction of the target must not cause a user installing or running a version of Rust or the Rust tools to be subject to any new license requirements.
>     - Compiling, linking, and emitting functional binaries, libraries, or other code for the target (whether hosted on the target itself or cross-compiling from another target) must not depend on proprietary (non-FOSS) libraries. Host tools built for the target itself may depend on the ordinary runtime libraries supplied by the platform and commonly used by other applications built for the target, but those libraries must not be required for code generation for the target; cross-compilation to the target must not require such libraries at all. For instance, `rustc` built for the target may depend on a common proprietary C runtime library or console output library, but must not depend on a proprietary code generation library or code optimization library. Rust's license permits such combinations, but the Rust project has no interest in maintaining such combinations within the scope of Rust itself, even at tier 3.
>     - "onerous" here is an intentionally subjective term. At a minimum, "onerous" legal/licensing terms include but are _not_ limited to: non-disclosure requirements, non-compete requirements, contributor license agreements (CLAs) or equivalent, "non-commercial"/"research-only"/etc terms, requirements conditional on the employer or employment of any particular Rust developers, revocable terms, any requirements that create liability for the Rust project or its developers or users, or any requirements that adversely affect the livelihood or prospects of the Rust project or its developers or users.

The tools consists of the cross-compiler toolchain (gcc-based). The RTEMS kernel (BSD license) and parts of the driver stack of FreeBSD (BSD license). All tools are FOSS and publicly available here: https://gitlab.rtems.org/rtems
There are also no new features or dependencies introduced to the Rust code.

> - Neither this policy nor any decisions made regarding targets shall create any binding agreement or estoppel by any party. If any member of an approving Rust team serves as one of the maintainers of a target, or has any legal or employment requirement (explicit or implicit) that might affect their decisions regarding a target, they must recuse themselves from any approval decisions regarding the target's tier status, though they may otherwise participate in discussions.

N/A to me. I am not a reviewer nor Rust team member.

> - Tier 3 targets should attempt to implement as much of the standard libraries as possible and appropriate (`core` for most targets, `alloc` for targets that can support dynamic memory allocation, `std` for targets with an operating system or equivalent layer of system-provided functionality), but may leave some code unimplemented (either unavailable or stubbed out as appropriate), whether because the target makes it impossible to implement or challenging to implement. The authors of pull requests are not obligated to avoid calling any portions of the standard library on the basis of a tier 3 target not implementing those portions.

`core` and `std` compile. Some advanced features of the `std` lib might not work yet. However, the goal of this tier 3 target it to make it easier for other people to build and run test applications to better identify the unsupported features and work towards enabling them.

> - The target must provide documentation for the Rust community explaining how to build for the target, using cross-compilation if possible. If the target supports running binaries, or running tests (even if they do not pass), the documentation must explain how to run such binaries or tests for the target, using emulation if possible or dedicated hardware if necessary.

Building is described in platform support doc. Running simple unit tests works. Running the test suite of the stdlib is currently not that easy. Trying to work towards that after the this target has been added to the nightly.

> - Tier 3 targets must not impose burden on the authors of pull requests, or other developers in the community, to maintain the target. In particular, do not post comments (automated or manual) on a PR that derail or suggest a block on the PR based on a tier 3 target. Do not send automated messages or notifications (via any medium, including via ````@`)``` to a PR author or others involved with a PR regarding a tier 3 target, unless they have opted into such messages.

Understood.

>     - Backlinks such as those generated by the issue/PR tracker when linking to an issue or PR are not considered a violation of this policy, within reason. However, such messages (even on a separate repository) must not generate notifications to anyone involved with a PR who has not requested such notifications.

Ok

> - Patches adding or updating tier 3 targets must not break any existing tier 2 or tier 1 target, and must not knowingly break another tier 3 target without approval of either the compiler team or the maintainers of the other tier 3 target.
>     - In particular, this may come up when working on closely related targets, such as variations of the same architecture with different features. Avoid introducing unconditional uses of features that another variation of the target may not have; use conditional compilation or runtime detection, as appropriate, to let each target run code supported by that target.

I think, I didn't add any breaking changes for any existing targets (see the comment regarding features above).

> - Tier 3 targets must be able to produce assembly using at least one of rustc's supported backends from any host target.

Can produce assembly code via the llvm backend (tested on Linux).

>
> If a tier 3 target stops meeting these requirements, or the target maintainers no longer have interest or time, or the target shows no signs of activity and has not built for some time, or removing the target would improve the quality of the Rust codebase, we may post a PR to remove it; any such PR will be CCed to the target maintainers (and potentially other people who have previously worked on the target), to check potential interest in improving the situation.GIAt this tier, the Rust project provides no official support for a target, so we place minimal requirements on the introduction of targets.

Understood.

r? compiler-team
2024-09-05 03:47:40 +02:00
Matthias Krüger e1da72c6e8
Rollup merge of #120736 - notriddle:notriddle/toc, r=t-rustdoc
rustdoc: add header map to the table of contents

## Summary

Add header sections to the sidebar TOC.

### Preview

![image](https://github.com/user-attachments/assets/eae4df02-86aa-4df4-8c61-a95685cd8829)

* http://notriddle.com/rustdoc-html-demo-9/toc/rust/std/index.html
* http://notriddle.com/rustdoc-html-demo-9/toc/rust-derive-builder/derive_builder/index.html

## Motivation

Some pages are very wordy, like these.

| crate | word count |
|--|--|
| [std::option](https://doc.rust-lang.org/stable/std/option/index.html) | 2,138
| [derive_builder](https://docs.rs/derive_builder/0.13.0/derive_builder/index.html) | 2,403
| [tracing](https://docs.rs/tracing/0.1.40/tracing/index.html) | 3,912
| [regex](https://docs.rs/regex/1.10.3/regex/index.html) | 8,412

This kind of very long document is more navigable with a table of contents, like Wikipedia's or the one [GitHub recently added](https://github.blog/changelog/2021-04-13-table-of-contents-support-in-markdown-files/) for READMEs.

In fact, the use case is so compelling, that it's been requested multiple times and implemented in an extension:

* https://github.com/rust-lang/rust/issues/80858
* https://github.com/rust-lang/rust/issues/28056
* https://github.com/rust-lang/rust/issues/14475
* https://rust.extension.sh/#show-table-of-content

(Some of these issues ask for more than this, so don’t close them.)

It's also been implemented by hand in some crates, because the author really thought it was needed. Protip: for a more exhaustive list, run [`site:docs.rs table of contents`](https://duckduckgo.com/?t=ffab&q=site%3Adocs.rs+table+of+contents&ia=web), though some of them are false positives.

* https://docs.rs/figment/0.10.14/figment/index.html#table-of-contents
* https://docs.rs/csv/1.3.0/csv/tutorial/index.html#table-of-contents
* https://docs.rs/axum/0.7.4/axum/response/index.html#table-of-contents
* https://docs.rs/regex-automata/0.4.5/regex_automata/index.html#table-of-contents

Unfortunately for these hand-built ToCs, because they're just part of the docs, there's no consistent way to turn them off if the reader doesn't want them. It's also more complicated to ensure they stay in sync with the docs they're supposed to describe, and they don't stay with you when you scroll like Wikipedia's [does now](https://uxdesign.cc/design-notes-on-the-2023-wikipedia-redesign-d6573b9af28d).

## Guide-level explanation

When writing docs for a top-level item, the first and second level of headers will be shown in an outline in the sidebar. In this context, "top level" means "not associated".

This means, if you're writing very long guides or explanations, and you want it to have a table of contents in the sidebar for its headings, the ideal place to attach it is usually the *module* or *crate*, because this page has fewer other things on it (and is the ideal place to describe "cross-cutting concerns" for its child items).

If you're reading documentation, and want to get rid of the table of contents, open the ![image](https://github.com/rust-lang/rust/assets/1593513/2ad82466-5fe3-4684-b1c2-6be4c99a8666) Settings panel and checkmark "Hide table of contents."

## Reference-level explanation

Top-level items have an outline generated. This works for potentially-malformed header trees by pairing a header with the nearest header with a higher level. For example:

```markdown
## A
# B
# C
## D
## E
```

A, B, and C are all siblings, and D and E are children of C.

Rustdoc only presents two layers of tree, but it tracks up to the full depth of 6 while preparing it.

That means that these two doc comment both generate the same outline:

```rust
/// # First
/// ## Second
struct One;
/// ## First
/// ### Second
struct Two;
```

## Drawbacks

The biggest drawback is adding more stuff to the sidebar.

My crawl through docs.rs shows this to, surprisingly, be less of a problem than I thought. The manually-built tables of contents, and the pages with dozens of headers, usually seem to be modules or crates, not types (where extreme scrolling would become a problem, since they already have methods to deal with).

The best example of a type with many headers is [vec::Vec](https://doc.rust-lang.org/1.75.0/std/vec/struct.Vec.html), which still only has five headers, not dozens like [axum::extract](https://docs.rs/axum/0.7.4/axum/extract/index.html).

## Rationale and alternatives

### Why in the existing sidebar?

The method links and the top-doc header links have more in common with each other than either of them do with the "In [parent module]" links, and should go together.

### Why limited to two levels?

The sidebar is pretty narrow, and I don't want too much space used by indentation. Making the sidebar wider, while it has some upsides, also takes up more space on middling-sized screens or tiled WMs.

### Why not line wrap?

That behaves strangely when resizing.

## Prior art

### Doc generators that have TOC for headers

https://hexdocs.pm/phoenix/Phoenix.Controller.html is very close, in the sense that it also has header sections directly alongside functions and types.

Another example, referenced as part of the [early sidebar discussion](https://github.com/rust-lang/rust/issues/37856) that added methods, Ruby will show a table of contents in the sidebar (for example, on the [ARGF](https://docs.ruby-lang.org/en/master/ARGF.html) class). According to their changelog, [they added it in 2013](06137bde8c/History.rdoc (400--2013-02-24-)).

Haskell seems to mix text and functions even more freely than Elixir. For example, this [Naming conventions](https://hackage.haskell.org/package/base-4.19.0.0/docs/Control-Monad.html#g:3) is plain text, and is immediately followed by functions. And the [Pandoc top level](https://hackage.haskell.org/package/pandoc-3.1.11.1/docs/Text-Pandoc.html) has items split up by function, rather than by kind. Their TOC matches exactly with the contents of the page.

### Doc generators that don't have header TOC, but still have headers

Elm, interestingly enough, seems to have the same setup that Rust used to have: sibling navigation between modules, and no index within a single page. [They keep Haskell's habit of named sections with machine-generated type signatures](https://package.elm-lang.org/packages/elm/browser/latest/Browser-Dom), though.

[PHP](https://www.php.net/manual/en/book.datetime.php), like elm, also has a right-hand sidebar with sibling navigation. However, PHP has a single page for a single method, unlike Rust's page for an entire "class." So even though these pages have headers, it's never more than ten at most. And when they have guides, those guides are also multi-page.

## Unresolved questions

* Writing recommendations for anyone who wants to take advantage of this.
* Right now, it does not line wrap. That might be a bad idea: a lot of these are getting truncated.
* Split sidebars, which I [tried implementing](https://rust-lang.zulipchat.com/#narrow/stream/266220-t-rustdoc/topic/Table.20of.20contents), are not required. The TOC can be turned off, if it's really a problem. Implemented in https://github.com/rust-lang/rust/pull/120818, but needs more, separate, discussion.

## Future possibilities

I would like to do a better job of distinguishing global navigation from local navigation. Rustdoc has a pretty reasonable information architecture, if only we did a better job of communicating it.

This PR aims, mostly, to help doc authors help their users by writing docs that can be more effectively skimmed. But it doesn't do anything to make it easier to tell the TOC and the Module Nav apart.
2024-09-05 03:47:40 +02:00
Matthias Krüger 8a60d0a5ec
Rollup merge of #101339 - the8472:ci-randomize-debug, r=Mark-Simulacrum
enable -Zrandomize-layout in debug CI builds

This builds rustc/libs/tools with `-Zrandomize-layout` on *-debug CI runners.

Only a handful of tests and asserts break with that enabled, which is promising. One test was fixable, the rest is dealt with by disabling them through new cargo features or compiletest directives.

The config.toml flag `rust.randomize-layout` defaults to false, so it has to be explicitly enabled for now.
2024-09-05 03:47:39 +02:00
bors 009e73825a Auto merge of #129936 - matthiaskrgr:rollup-0s8xycb, r=matthiaskrgr
Rollup of 9 pull requests

Successful merges:

 - #127692 (Suggest `impl Trait` for References to Bare Trait in Function Header)
 - #128701 (Don't Suggest Labeling `const` and `unsafe` Blocks )
 - #128934 (Non-exhaustive structs may be empty)
 - #129630 (Document the broken C ABI of `wasm32-unknown-unknown`)
 - #129863 (update comment regarding TargetOptions.features)
 - #129896 (do not attempt to prove unknowable goals)
 - #129926 (Move `SanityCheck` and `MirPass`)
 - #129928 (rustc_driver_impl: remove some old dead logic)
 - #129930 (include 1.80.1 release notes on master)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-09-04 22:58:51 +00:00
Folkert de Vries 49e3b9a2d2 fix ICE when `asm_const` and `const_refs_to_static` are combined 2024-09-04 20:06:38 +02:00
Folkert de Vries f7679d0507 propagate `tainted_by_errors` in `MirBorrowckCtxt::emit_errors` 2024-09-04 20:06:33 +02:00
liushuyu 6e4c5c10b9 tests: add an assembly scanning test for s390x backchain switch 2024-09-04 08:10:53 -06:00
clubby789 5b96ae7106 Don't codegen `expect` in opt-level=0 2024-09-04 11:49:00 +00:00
Michael Goulet 8860008e7f Re-parent the by-move body 2024-09-04 06:28:32 -04:00
Michael Goulet 5525043ac8 Rename dump of coroutine by-move-body to be more consistent, adjust test 2024-09-03 16:22:28 -04:00
Guillaume Gomez 7157f98cb4 Fix square corners on line numbers when code is collapsed 2024-09-03 22:17:04 +02:00
Nadrieril 040239465a Add an internal lint that warns when accessing untracked data 2024-09-03 19:14:19 +02:00
Matthias Krüger 485fd3815c
Rollup merge of #129896 - lcnr:bail-on-unknowable, r=jackh726
do not attempt to prove unknowable goals

In case a goal is unknowable, we previously still checked all other possible ways to prove this goal, even though its final result is already guaranteed to be ambiguous. By ignoring all other candidates in that case we can avoid a lot of unnecessary work, fixing the performance regression in typenum found in #121848.

This is already the behavior in the old solver. This could in theory cause future-compatability issues as considering fewer goals unknowable may end up causing performance regressions/hangs. I am quite confident that this will not be an issue.

r? ``@compiler-errors``
2024-09-03 19:13:26 +02:00
Matthias Krüger e7504ac704
Rollup merge of #128934 - Nadrieril:fix-empty-non-exhaustive, r=compiler-errors
Non-exhaustive structs may be empty

This is a follow-up to a discrepancy noticed in https://github.com/rust-lang/rust/pull/122792: today, the following struct is considered inhabited (non-empty) outside its defining crate:
```rust
#[non_exhaustive]
pub struct UninhabitedStruct {
    pub never: !,
    // other fields
}
```

`#[non_exhaustive]` on a struct should mean that adding fields to it isn't a breaking change. There is no way that adding fields to this struct could make it non-empty since the `never` field must stay and is inconstructible. I suspect this was implemented this way due to confusion with `#[non_exhaustive]` enums, which indeed should be considered non-empty outside their defining crate.

I propose that we consider such a struct uninhabited (empty), just like it would be without the `#[non_exhaustive]` annotation.

Code that doesn't pass today and will pass after this:
```rust
// In a different crate
fn empty_match_on_empty_struct<T>(x: UninhabitedStruct) -> T {
    match x {}
}
```

This is not a breaking change.

r? ``@compiler-errors``
2024-09-03 19:13:24 +02:00
Matthias Krüger 51c686f32b
Rollup merge of #128701 - veera-sivarajan:fix-128604, r=estebank
Don't Suggest Labeling `const` and `unsafe` Blocks

Fixes #128604

Previously, both anonymous constant blocks (E.g. The labeled block
inside `['_'; 'block: { break 'block 1 + 2; }]`) and inline const
blocks (E.g. `const { ... }`) were considered to be the same
kind of blocks. This caused the compiler to incorrectly suggest
labeling both the blocks when only anonymous constant blocks can be
labeled.

This PR adds an other enum variant to `Context` so that both the
blocks can be handled appropriately.

Also, adds some doc comments and removes unnecessary `&mut` in a
couple of places.
2024-09-03 19:13:23 +02:00
Matthias Krüger f75a1954eb
Rollup merge of #127692 - veera-sivarajan:bugfix-125139, r=estebank
Suggest `impl Trait` for References to Bare Trait in Function Header

Fixes #125139

This PR suggests `impl Trait` when `&Trait` is found as a function parameter type or return type. This makes use of existing diagnostics by adding `peel_refs()` when checking for type equality.

Additionaly, it makes a few other improvements:
1. Checks if functions inside impl blocks have bare trait in their headers.
2. Introduces a trait `NextLifetimeParamName` similar to the existing `NextTypeParamName` for suggesting a lifetime name. Also, abstracts out the common logic between the two trait impls.

### Related Issues
I ran into a bunch of related diagnostic issues but couldn't fix them within the scope of this PR. So, I have created the following issues:
1. [Misleading Suggestion when Returning a Reference to a Bare Trait from a Function](https://github.com/rust-lang/rust/issues/127689)
2. [Verbose Error When a Function Takes a Bare Trait as Parameter](https://github.com/rust-lang/rust/issues/127690)
3. [Incorrect Suggestion when Returning a Bare Trait from a Function](https://github.com/rust-lang/rust/issues/127691)

r​? ```@estebank``` since you implemented  #119148
2024-09-03 19:13:23 +02:00
Bryanskiy 59885f5065 Delegation refactoring: add builders for generics inheritance 2024-09-03 15:38:39 +03:00
Chris Denton c811d3126f
More robust extension checking 2024-09-03 14:36:21 +02:00
Jan Sommer 124454cda8 rtems: Add spec file for arm_rtems6_eabihf 2024-09-03 09:20:49 +02:00
Jan Sommer 6f435cb07f Port std library to RTEMS 2024-09-03 09:19:29 +02:00
lcnr 6188aae369 do not attempt to prove unknowable goals 2024-09-03 08:35:23 +02:00
Guillaume Gomez 55bc638a1d Fix wrong padding for expanded scraped example 2024-09-03 01:04:59 +02:00
Nadrieril 6f6a6bc710 Non-exhaustive structs may be empty 2024-09-02 21:16:37 +02:00
bors bd53aa3bf7 Auto merge of #129317 - compiler-errors:expectation-subtyping, r=lcnr
Use equality when relating formal and expected type in arg checking

#129059 uncovered an interesting issue in argument checking. When we check arguments, we create three sets of types:
* Formals
* Expected
* Actuals

The **actuals** are the types of the argument expressions themselves. The **formals** are the types from the signature that we're checking. The **expected** types are the formal types, but passed through `expected_inputs_for_expected_outputs`:

a971212545/compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs (L691-L725)

This method attempts to constrain the formal inputs by relating the [expectation](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_hir_typeck/expectation/enum.Expectation.html) of the call expression and the formal output.

When we check an argument, we get the expression's actual type, and then we first attempt to coerce it to the expected type:

a971212545/compiler/rustc_hir_typeck/src/fn_ctxt/checks.rs (L280-L293)

Then we subtype the expected type and the formal type:

a971212545/compiler/rustc_hir_typeck/src/fn_ctxt/checks.rs (L299-L305)

However, since we are now recording the right coercion target (since #129059), we now end up recording the expected type to the typeck results, rather than the actual.

Since that expected type was [fudged](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_infer/infer/struct.InferCtxt.html#method.fudge_inference_if_ok), it has fresh variables. And since the expected type is only subtyped against the formal type, if that expected type has a bivariant parameter, it will likely remain unconstrained since `Covariant * Bivariant = Bivariant` according to [xform](https://doc.rust-lang.org/nightly/nightly-rustc/rustc_middle/ty/enum.Variance.html#method.xform). This leads to an unconstrained type variable in writeback.

AFAICT, there's no reason for us to be using subtyping here, though. The expected output is already related to the expectation by subtyping:

a971212545/compiler/rustc_hir_typeck/src/fn_ctxt/_impl.rs (L713)

So the formals don't need "another" indirection of subtyping in the argument checking... So I've changed it to use equality here. We could alternatively fix this by requiring WF for all the expected types to constrain their bivariant parameters, but this seems a bit overkill.

Fixes #129286
2024-09-02 16:08:50 +00:00
Veera 265cd14cd4 Update Tests 2024-09-02 11:45:51 -04:00
Guillaume Gomez e3af6dc239 Simplify CSS but wrapping scraped example into a div and move the title out of the code block 2024-09-02 15:59:00 +02:00
Rémy Rakic a178559a03 address review comments 2024-09-02 08:37:55 +00:00
Matthias Krüger 38b6a66def
Rollup merge of #129858 - compiler-errors:async-def, r=cjgillot
Replace walk with visit so we dont skip outermost expr kind in def collector

This affects async closures with macros as their body expr. Fixes #129855.

r? ``@cjgillot`` or anyone else
2024-09-02 04:19:31 +02:00
Matthias Krüger 5c3370d684
Rollup merge of #129837 - aDotInTheVoid:test-better-json, r=jieyouxu
Actually parse stdout json, instead of using hacky contains logic.

Fixes up the test added in #128963, to actually parse the stdout to JSON, instead of just checking that it contains `{"`.

CC ``@GuillaumeGomez``

r? ``@jieyouxu``
2024-09-02 04:19:30 +02:00
Matthias Krüger e0039171ff
Rollup merge of #129678 - compiler-errors:type-ir-inherent, r=fmease
Deny imports of `rustc_type_ir::inherent` outside of type ir + new trait solver

We shouldn't encourage using `rustc_type_ir::inherent` outside of the new solver[^1], though this can happen by accident due to rust-analyzer, for example. See https://github.com/rust-lang/rust/pull/127537#discussion_r1733813842 for an example in practice.

r? fmease

[^1]: Unless we go the fully radical approach of always using these inherent methods everywhere in favor of inherent methods, which would be a major overhaul of the compiler, IMO. I don't really want to consider that possibility right now, tho.
2024-09-02 04:19:28 +02:00
Matthias Krüger c90991db17
Rollup merge of #127474 - tesuji:foldable-inline-derefs, r=t-rustdoc
doc: Make block of inline Deref methods foldable

After:
![image](https://github.com/rust-lang/rust/assets/15225902/3e8ab320-dbf7-436f-9be0-d0ef82664663)
Before:
![image](https://github.com/rust-lang/rust/assets/15225902/f6f7635d-d4c3-437e-a2d9-147726287b05)

Fix  #127470.

Current status:
- [x] Bug when hovering over title "Methods from ...": The anchor sign $ overlaps with `[-]`: https://github.com/rust-lang/rust/pull/127474#issuecomment-2222930038
    => Fixed by https://github.com/rust-lang/rust/pull/127474#issuecomment-2228886292
2024-09-02 04:19:27 +02:00
Guillaume Gomez 01d8235ae1 Fix scraped examples background gradient 2024-09-02 00:02:03 +02:00
Guillaume Gomez 5a85632623 Correctly handle code examples buttons position 2024-09-01 23:43:27 +02:00
schvv31n f2696ab4d3 rustdoc: normalise type/field names in rustdoc-json-types/jsondoclint 2024-09-01 23:58:08 +03:00
cyrgani 4a93071aa1 add a few more crashtests 2024-09-01 22:28:23 +02:00
bors 94885bc699 Auto merge of #129854 - Kobzol:revert-127537, r=lqd
Revert "Auto merge of #127537 - veluca93:struct_tf, r=BoxyUwU"

This reverts https://github.com/rust-lang/rust/pull/127537 (commit acb4e8b625), reversing changes made to 100fde5246.

Opening to see if this can help resolve the recent perf. results [instability](https://rust-lang.zulipchat.com/#narrow/stream/247081-t-compiler.2Fperformance/topic/Weird.20perf.20results).
2024-09-01 19:46:46 +00:00
Guillaume Gomez 4825fb198f Add missing CSS variables in GUI test for `custom-theme.css` 2024-09-01 20:49:41 +02:00
Guillaume Gomez dd5f7bc628 Add GUI regression test for scraped examples title position on mobile 2024-09-01 20:49:41 +02:00
Guillaume Gomez 84259ff23b Add GUI tests to ensure that rounded corners on code blocks are working as expected 2024-09-01 20:49:41 +02:00
Michael Goulet 91854453f2 Deny imports of rustc_type_ir::inherent outside of type ir + new trait solver 2024-09-01 12:16:18 -04:00
bors a48861a627 Auto merge of #127313 - cjgillot:single-expect, r=jieyouxu
Rewrite lint_expectations in a single pass.

This PR aims at reducing the perf regression from https://github.com/rust-lang/rust/pull/120924#issuecomment-2202486203 with drive-by simplifications.

Basically, instead of using the lint level builder, which is slow, this PR splits `lint_expectations` logic in 2:
- listing the `LintExpectations` is done in `shallow_lint_levels_on`, on a per-owner basis;
- building the unstable->stable expectation id map is done by iterating on attributes.

r? ghost for perf
2024-09-01 15:50:48 +00:00
Michael Goulet 7ab44cddc9 Replace walk with visit so we dont skip outermost expr kind in def collector 2024-09-01 11:16:50 -04:00
Jakub Beránek 47e6b5deed Revert "Auto merge of #127537 - veluca93:struct_tf, r=BoxyUwU"
This reverts commit acb4e8b625, reversing
changes made to 100fde5246.
2024-09-01 16:35:53 +02:00
Ralf Jung 19908ff7a3 stabilize const_float_bits_conv 2024-09-01 12:38:59 +02:00
Mateusz Mikuła 4ee58db2f1 Upgrade CI's mingw-w64 toolchain 2024-09-01 12:37:26 +02:00
Michael Goulet 384aed834c Do not call query to compute coroutine layout for synthetic body of async closure 2024-09-01 06:13:04 -04:00
bors 1a1cc050d8 Auto merge of #127897 - nyurik:add-qnx-70-target, r=saethlin
add `aarch64_unknown_nto_qnx700` target - QNX 7.0 support for aarch64le

This backports the QNX 7.1 aarch64 implementation to 7.0.

* [x] required `-lregex` disabled, see https://github.com/rust-lang/libc/pull/3775 (released in libc 0.2.156)
* [x] uses `libgcc.a` instead of `libgcc_s.so` (7.0 used ancient GCC 5.4 which didn't have gcc_s)
* [x] a fix in `backtrace` crate to support stack traces https://github.com/rust-lang/backtrace-rs/pull/648

This PR bumps libc dependency to 0.2.158

CC: to the folks who did the [initial implementation](https://doc.rust-lang.org/rustc/platform-support/nto-qnx.html): `@flba-eb,` `@gh-tr,` `@jonathanpallant,` `@japaric`

# Compile target

```bash
# Configure qcc build environment
source _path_/_to_/qnx7.0/qnxsdp-env.sh

# Tell rust to use qcc when building QNX 7.0 targets
export build_env='
    CC_aarch64-unknown-nto-qnx700=qcc
    CFLAGS_aarch64-unknown-nto-qnx700=-Vgcc_ntoaarch64le_cxx
    CXX_aarch64-unknown-nto-qnx700=qcc
    AR_aarch64_unknown_nto_qnx700=ntoaarch64-ar'

# Build rust compiler, libs, and the remote test server
env $build_env ./x.py build \
  --target x86_64-unknown-linux-gnu,aarch64-unknown-nto-qnx700 \
  rustc library/core library/alloc library/std src/tools/remote-test-server

rustup toolchain link stage1 build/host/stage1
```

# Compile "hello world"

```bash
source _path_/_to_/qnx7.0/qnxsdp-env.sh

cargo new hello_world
cd hello_world
cargo +stage1 build --release --target aarch64-unknown-nto-qnx700
```

# Configure a remote for testing

Do this from a new shell - we will need to run more commands in the previous one.  I ran into these two issues, and found some workarounds.

* Temporary dir might not work properly
* Default `remote-test-server` has issues binding to an address

```
# ./remote-test-server
starting test server
thread 'main' panicked at src/tools/remote-test-server/src/main.rs:175:29:
called `Result::unwrap()` on an `Err` value: Os { code: 249, kind: AddrNotAvailable, message: "Can't assign requested address" }
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
```

Specifying `--bind` param actually fixes that, and so does setting `TMPDIR` properly.

```bash
# Copy remote-test-server to remote device. You may need to use sftp instead.
# ATTENTION: Note that the path is different from the one in the remote testing documentation for some reason
scp ./build/x86_64-unknown-linux-gnu/stage1-tools-bin/remote-test-server  qnxdevice:/path/

# Run ssh with port forwarding - so that rust tester can connect to the local port instead
ssh -L 12345:127.0.0.1:12345 qnxdevice

# on the device, run
rm -rf tmp && mkdir -p tmp && TMPDIR=$PWD/tmp ./remote-test-server --bind 0.0.0.0:12345
```

# Run test suit

Assume all previous environment variables are still set, or re-init them

```bash
export TEST_DEVICE_ADDR="localhost:12345"

# tidy needs to be skipped due to using un-published libc dependency
export exclude_tests='
    --exclude src/bootstrap
    --exclude src/tools/error_index_generator
    --exclude src/tools/linkchecker
    --exclude src/tools/tidy
    --exclude tests/ui-fulldeps
    --exclude rustc
    --exclude rustdoc
    --exclude tests/run-make-fulldeps'

env $build_env ./x.py test  $exclude_tests --stage 1 --target aarch64-unknown-nto-qnx700
```

try-job: dist-x86_64-msvc
2024-09-01 08:00:25 +00:00
Matthias Krüger f040e689c0
Rollup merge of #129780 - cyrgani:master, r=compiler-errors
add crashtests for several old unfixed ICEs

Adds several new crashtests for some older ICEs that did not yet have any.
Tests were added for #128097, #119095, #117460 and #126443.
2024-09-01 03:58:05 +02:00
Matthias Krüger d24336b8c9
Rollup merge of #129672 - saethlin:enum-debuginfo-tests, r=Mark-Simulacrum
Make option-like-enum.rs UB-free and portable

Fixes https://github.com/rust-lang/rust/issues/129662

(or, at least the parts of it that aren't https://github.com/rust-lang/rust/issues/128973)
2024-09-01 03:58:05 +02:00
Matthias Krüger 07d5c250be
Rollup merge of #129493 - cjgillot:early-opaque-def, r=petrochenkov
Create opaque definitions in resolver.

Implementing https://github.com/rust-lang/rust/issues/129023#issuecomment-2306079532

That was easier than I expected.

r? `@petrochenkov`
2024-09-01 03:58:04 +02:00
Matthias Krüger 1063c0dd37
Rollup merge of #129207 - GrigorenkoPV:elided-is-named, r=cjgillot
Lint that warns when an elided lifetime ends up being a named lifetime

As suggested in https://github.com/rust-lang/rust/issues/48686#issuecomment-1817334575

Fixes #48686
2024-09-01 03:58:03 +02:00
Alona Enraght-Moony f78979e687 Actually parse stdout json, instead of using hacky contains logic. 2024-08-31 22:08:38 +00:00
The 8472 f3bc08adbd ignore/fix layout-sensitive tests 2024-08-31 23:56:45 +02:00
bors a7399ba69d Auto merge of #129831 - matthiaskrgr:rollup-befq6zx, r=matthiaskrgr
Rollup of 11 pull requests

Successful merges:

 - #128523 (Add release notes for 1.81.0)
 - #129605 (Add missing `needs-llvm-components` directives for run-make tests that need target-specific codegen)
 - #129650 (Clean up `library/profiler_builtins/build.rs`)
 - #129651 (skip stage 0 target check if `BOOTSTRAP_SKIP_TARGET_SANITY` is set)
 - #129684 (Enable Miri to pass pointers through FFI)
 - #129762 (Update the `wasm-component-ld` binary dependency)
 - #129782 (couple more crash tests)
 - #129816 (tidy: say which feature gate has a stability issue mismatch)
 - #129818 (make the const-unstable-in-stable error more clear)
 - #129824 (Fix code examples buttons not appearing on click on mobile)
 - #129826 (library: Fix typo in `core::mem`)

r? `@ghost`
`@rustbot` modify labels: rollup
2024-08-31 20:59:27 +00:00
Camille GILLOT f68f66538a Create opaque definitions in resolver. 2024-08-31 20:14:43 +00:00
Michael Goulet 95b9ecd6d6 Inline expected_inputs_for_expected_output into check_argument_types/check_expr_struct_fields 2024-08-31 16:08:29 -04:00
Michael Goulet c3f9c4f4d4 Use equality when relating formal and expected type in arg checking 2024-08-31 16:07:41 -04:00
Matthias Krüger b8b2a65035
Rollup merge of #129818 - RalfJung:const-stability, r=compiler-errors
make the const-unstable-in-stable error more clear

The default should be to add `rustc_const_unstable`, not `rustc_allow_const_fn_unstable`.

Also I discovered our check for missing const stability attributes on stable functions -- but strangely that check only kicks in for "reachable" functions. `check_missing_stability` checks for reachability since all reachable functions must have a stability attribute, but I would say if a function has `#[stable]` it should also have const-stability attributes regardless of reachability.
2024-08-31 20:36:27 +02:00
Matthias Krüger 1e0cc8bec3
Rollup merge of #129782 - matthiaskrgr:c, r=jieyouxu
couple more crash tests

r? ```@jieyouxu```
2024-08-31 20:36:26 +02:00
Matthias Krüger d354d4ddd7
Rollup merge of #129605 - jieyouxu:needs-llvm-components, r=Mark-Simulacrum
Add missing `needs-llvm-components` directives for run-make tests that need target-specific codegen

Without suitable `needs-llvm-components` directives, some run-make tests exercising target-specific codegen can fail if the LLVM used is built without the necessary components. Currently, the list is:

```
tests\run-make\print-target-list
tests\run-make\print-to-output
tests\run-make\print-cfg
tests\run-make\target-without-atomic-cas
```

This PR also skips tidy checks for revisions and `needs-llvm-components` for run-make tests since revisions are not supported.

Fixes #129390.
Fixes #127895.

cc ``@petrochenkov`` who noticed this, thanks! Would be great if you could confirm that this fixes the test errors for you locally.
2024-08-31 20:36:23 +02:00
Camille GILLOT 111b0a97b4 Rewrite lint_expectations in a single pass. 2024-08-31 14:00:54 +00:00
Ralf Jung e3b1966137 make the const-unstable-in-stable error more clear 2024-08-31 15:11:48 +02:00
Matthias Krüger ff0c98663e
Rollup merge of #129760 - cuviper:old-timey, r=compiler-errors
Make the "detect-old-time" UI test more representative

The test code did have an inference failure, but that would have failed
on Rust 1.79 and earlier too. Now it is rewritten to be specifically
affected by 1.80's `impl FromIterator<_> for Box<str>`.
2024-08-31 14:46:10 +02:00
Matthias Krüger 6b9ed71c21
Rollup merge of #129757 - saethlin:half-a-recursion, r=compiler-errors
Add a test for trait solver overflow in MIR inliner cycle detection

This test is a combination of the reproducer posted here: https://github.com/rust-lang/rust/issues/128887#issuecomment-2314198229 and the existing test for polymorphic recursion: 784d444733/tests/mir-opt/inline/polymorphic_recursion.rs

r? ```@compiler-errors```
2024-08-31 14:46:10 +02:00
Matthias Krüger 1c51e5b110
Rollup merge of #129711 - lqd:nll-mir-dumps, r=compiler-errors
Expand NLL MIR dumps

This PR is a first step to clean up and expand NLL MIR dumps:
- by restoring the "mir-include-spans" comments which are useful for `-Zdump-mir=nll`
- by adding the list of borrows to NLL MIR dumps, where they are introduced in the CFG and in which region

Comments in MIR dumps were turned off in #112346, but as shown in #114652 they were still useful for us working with NLL MIR dumps. So this PR pulls `-Z mir-include-spans` into its own options struct, so that passes dumping MIR can override them if need be. The rest of the compiler is not affected, only the "nll" pass dumps have these comments enabled again. The CLI still has priority when specifying the flag, so that we can explicitly turn them off in the `mir-opt` tests to keep blessed dumps easier to work with (which was one of the points of #112346).

Then, as part of a couple steps to improve NLL/polonius MIR dumps and `.dot` visualizations, I've also added the list of borrows and where they're introduced. I'm doing all this to help debug some polonius scope issues in my prototype location-sensitive analysis :3. I'll probably add member constraints soon.
2024-08-31 14:46:07 +02:00
Matthias Krüger ea5bb99c0f
Rollup merge of #129659 - RalfJung:const-fn-lang-feat, r=fee1-dead
const fn stability checking: also check declared language features

Fixes https://github.com/rust-lang/rust/issues/129656

`@oli-obk` I assume it is just an oversight that this didn't use `features().declared()`? Or is there a deep reason that this must only check `declared_lib_features`?
2024-08-31 14:46:06 +02:00
Pavel Grigorenko a9b959a020 elided_named_lifetimes: bless & add tests 2024-08-31 15:35:42 +03:00
Ralf Jung c2984179d9 const fn stability checking: also check declared language features 2024-08-31 12:14:05 +02:00
Matthias Krüger 9f3ce40718
Rollup merge of #129366 - petrochenkov:libsearch, r=jieyouxu
linker: Synchronize native library search in rustc and linker

Also search for static libraries with alternative naming (`libname.a`) on MSVC when producing executables or dynamic libraries, and not just rlibs.

This unblocks https://github.com/rust-lang/rust/pull/123436.

try-job: x86_64-msvc
2024-08-31 10:08:53 +02:00
Matthias Krüger defc245d06
Rollup merge of #129123 - aDotInTheVoid:rustdoc-json-self, r=fmease
rustdoc-json: Add test for `Self` type

Inspired by #128471, the rustdoc-json suite had no tests in place for the `Self` type. This PR adds one.

I've also manually checked locally that this test passes on 29e924841f, confirming that adding `clean::Type::SelfTy` didn't change the JSON output. (potentially adding a self type to json (insead of (ab)using generic) is tracked in #128522)

Updates #81359

r? ````````@fmease````````
2024-08-31 10:08:52 +02:00
Matthias Krüger 1fd0c71818
Rollup merge of #120221 - compiler-errors:statements-are-not-patterns, r=nnethercote
Don't make statement nonterminals match pattern nonterminals

Right now, the heuristic we use to check if a token may begin a pattern nonterminal falls back to `may_be_ident`:
ef71f1047e/compiler/rustc_parse/src/parser/nonterminal.rs (L21-L37)

This has the unfortunate side effect that a `stmt` nonterminal eagerly matches against a `pat` nonterminal, leading to a parse error:
```rust
macro_rules! m {
    ($pat:pat) => {};
    ($stmt:stmt) => {};
}

macro_rules! m2 {
    ($stmt:stmt) => {
        m! { $stmt }
    };
}

m2! { let x = 1 }
```

This PR fixes it by more accurately reflecting the set of nonterminals that may begin a pattern nonterminal.

As a side-effect, I modified `Token::can_begin_pattern` to work correctly and used that in `Parser::nonterminal_may_begin_with`.
2024-08-31 10:08:51 +02:00
Guillaume Gomez 5b75f8a892 Update rustdoc GUI tests 2024-08-31 00:12:16 +02:00
Rajveer b324fcb169 [testsuite][cleanup] Remove all usages of `dont_merge` hack to avoid function merging
Resolves #129438

The `-Zmerge-functions=disabled` compile flag exists for this purpose.
2024-08-31 01:12:41 +05:30
cyrgani fff063ee77 add crashtests for several old unfixed ICEs 2024-08-30 12:50:07 +02:00
Matthias Krüger 355d7c9ecd couple more crash tests 2024-08-30 12:38:22 +02:00
Rémy Rakic dff3d3588d add borrows to NLL MIR dumps
explicitly disable `-Zmir-include-spans` in mir-opt tests

This will override the NLL default of true, and keep the blessed dumps
easier to work with.
2024-08-30 07:14:31 +00:00
Yuri Astrakhan f41e0bb41d Squashed `aarch64_unknown_nto_qnx700` support 2024-08-30 01:19:55 -04:00
Josh Stone c339541f73 Make the "detect-old-time" UI test more representative
The test code did have an inference failure, but that would have failed
on Rust 1.79 and earlier too. Now it is rewritten to be specifically
affected by 1.80's `impl FromIterator<_> for Box<str>`.
2024-08-29 13:58:43 -07:00
Ben Kimock c71ede368c Add a test for trait solver overflow in MIR inliner cycle detection 2024-08-29 16:20:08 -04:00
Guillaume Gomez 7dc2caba7b
Rollup merge of #129690 - Oneirical:run-make-tidbits, r=jieyouxu
Add `needs-unwind` compiletest directive to `libtest-thread-limit` and replace some `Path` with `path` in `run-make`

Part of #121876 and the associated [Google Summer of Code project](https://blog.rust-lang.org/2024/05/01/gsoc-2024-selected-projects.html).

This PR does two things:

1. Add this to `libtest-thread-limit` ([Why?](https://github.com/rust-lang/rust/pull/128507#issuecomment-2315158014))
```
//@ needs-unwind
// Reason: this should be ignored in cg_clif (Cranelift) CI and anywhere
// else that uses panic=abort.
```

2. Use `path` instead of `Path` to simplify multiple run-make tests.
2024-08-29 16:21:48 +02:00
Guillaume Gomez a65404aba4
Rollup merge of #129316 - dingxiangfei2009:riscv64-imac-scs, r=nnethercote
riscv64imac: allow shadow call stack sanitizer

cc `@Darksonn` for shadow call stack sanitizer support on RV64IMAC and RV64GC
2024-08-29 16:21:47 +02:00
Guillaume Gomez d5c40d03dc
Rollup merge of #128970 - DianQK:lint-llvm-ir, r=nikic
Add `-Zlint-llvm-ir`

This flag is similar to `-Zverify-llvm-ir` and allows us to lint the generated IR.

r? compiler
2024-08-29 16:21:47 +02:00
Guillaume Gomez 015e9371e0
Rollup merge of #123940 - kornelski:remove-derived-debug, r=Urgau
debug-fmt-detail option

I'd like to propose a new option that makes `#[derive(Debug)]` generate no-op implementations that don't print anything, and makes `{:?}` in format strings a no-op.

There are a couple of motivations for this:

1. A more thorough stripping of debug symbols. Binaries stripped of debug symbols still retain some of them through `Debug` implementations. It's hard to avoid that without compiler's help, because debug formatting can be used in many places, including dependencies, and their loggers, asserts, panics, etc.
   * In my testing it gives about 2% binary size reduction on top of all other binary-minimizing best practices (including `panic_immediate_abort`). There are targets like Web WASM or embedded where users pay attention to binary sizes.
   * Users distributing closed-source binaries may not want to "leak" any symbol names as a matter of principle.
2. Adds ability to test whether code depends on specifics of the `Debug` format implementation in unwise ways (e.g. trying to get data unavailable via public interface, or using it as a serialization format). Because current Rust's debug implementation doesn't change, there's a risk of it becoming a fragile de-facto API that [won't be possible to change in the future](https://www.hyrumslaw.com/). An option that "breaks" it can act as a [grease](https://www.rfc-editor.org/rfc/rfc8701.html).

This implementation is a `-Z fmt-debug=opt` flag that takes:

* `full` — the default, current state.
* `none` — makes derived `Debug` and `{:?}` no-ops. Explicit `impl Debug for T` implementations are left unharmed, but `{:?}` format won't use them, so they may get dead-code eliminated if they aren't invoked directly.
* `shallow` — makes derived `Debug` print only the type's name, without recursing into fields. Fieldless enums print their variant names. `{:?}` works.

The `shallow` option is a compromise between minimizing the `Debug` code, and compatibility. There are popular proc-macro crates that use `Debug::fmt` as a way to convert enum values into their Rust source code.

There's a corresponding `cfg` flag: `#[cfg(fmt_debug = "none")]` that can be used in user code to react to this setting to minimize custom `Debug` implementations or remove unnecessary formatting helper functions.
2024-08-29 16:21:46 +02:00
Oneirical 65cb5deedb Use path instead of Path in some run-make tests 2024-08-29 10:15:17 -04:00
Oneirical da43f95dd3 Add needs-unwind compiletest directive to libtest-thread-limit 2024-08-29 10:13:48 -04:00
Ding Xiang Fei 9c29b33c7e
riscv64imac: allow shadow call stack sanitizer 2024-08-29 21:48:48 +08:00
DianQK 9589eb95d2
Add `-Zlint-llvm-ir` 2024-08-29 18:12:31 +08:00