Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rollup of 14 pull requests #122711

Closed
wants to merge 36 commits into from

Conversation

workingjubilee
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

clubby789 and others added 30 commits March 6, 2024 12:01
when it is the default value of a generic param
A bit of an inelegant fix but given that the error is created only
after call to `const_eval_poly()` and that the calling function
cannot propagate the error anywhere else, the error has to be
explicitly handled inside `mono_item.rs`.
Co-authored-by: Mateusz Mikuła <mati865@gmail.com>
They match on almost the same patterns, which is fishy.

Also turn `associated_body` into a method and do some cleanups nearby the call sites
…le times

There already were inconsistencies, so this ensures we don't introduce subtle surprising bugs
…y-generic-tys, r=compiler-errors

Reject overly generic assoc const binding types

Split off from rust-lang#119385 to make rust-lang#119385 easier to review.

---

In the *instantiated* type of assoc const bindings

1. reject **early-bound generic params**
   * Provide a rich error message instead of ICE'ing ([rust-lang#108271](rust-lang#108271)).
   * This is a temporary and semi-artificial restriction until the arrival of *generic const generics*.
   * It's quite possible that rustc could already perfectly support this subset of generic const generics if we just removed some checks (some `.no_bound_vars().expect(…)`) but even if that was the case, I'd rather gate it behind a new feature flag. Reporting an error instead of ICE'ing is a good first step towards an eventual feature gate error.
2. reject **escaping late-bound generic params**
   * They lead to ICEs before & I'm pretty sure that they remain incorrect even in a world with *generic const generics*

---

Together with rust-lang#118668 & rust-lang#119385, this supersedes rust-lang#118360.
Fixes rust-lang#108271.
…piler-errors

Use hir::Node helper methods instead of repeating the same impl multiple times

I wanted to do something entirely different and stumbled upon a bunch of cleanups
…li-obk

Stabilize associated type bounds (RFC 2289)

This PR stabilizes associated type bounds, which were laid out in [RFC 2289]. This gives us a shorthand to express nested type bounds that would otherwise need to be expressed with nested `impl Trait` or broken into several `where` clauses.

### What are we stabilizing?

We're stabilizing the associated item bounds syntax, which allows us to put bounds in associated type position within other bounds, i.e. `T: Trait<Assoc: Bounds...>`. See [RFC 2289] for motivation.

In all position, the associated type bound syntax expands into a set of two (or more) bounds, and never anything else (see "How does this differ[...]" section for more info).

Associated type bounds are stabilized in four positions:
* **`where` clauses (and APIT)** - This is equivalent to breaking up the bound into two (or more) `where` clauses. For example, `where T: Trait<Assoc: Bound>` is equivalent to `where T: Trait, <T as Trait>::Assoc: Bound`.
* **Supertraits** - Similar to above, `trait CopyIterator: Iterator<Item: Copy> {}`. This is almost equivalent to breaking up the bound into two (or more) `where` clauses; however, the bound on the associated item is implied whenever the trait is used. See rust-lang#112573/rust-lang#112629.
* **Associated type item bounds** - This allows constraining the *nested* rigid projections that are associated with a trait's associated types. e.g. `trait Trait { type Assoc: Trait2<Assoc2: Copy>; }`.
* **opaque item bounds (RPIT, TAIT)** - This allows constraining associated types that are associated with the opaque without having to *name* the opaque. For example, `impl Iterator<Item: Copy>` defines an iterator whose item is `Copy` without having to actually name that item bound.

The latter three are not expressible in surface Rust (though for associated type item bounds, this will change in rust-lang#120752, which I don't believe should block this PR), so this does represent a slight expansion of what can be expressed in trait bounds.

### How does this differ from the RFC?

Compared to the RFC, the current implementation *always* desugars associated type bounds to sets of `ty::Clause`s internally. Specifically, it does *not* introduce a position-dependent desugaring as laid out in [RFC 2289], and in particular:
* It does *not* desugar to anonymous associated items in associated type item bounds.
* It does *not* desugar to nested RPITs in RPIT bounds, nor nested TAITs in TAIT bounds.

This position-dependent desugaring laid out in the RFC existed simply to side-step limitations of the trait solver, which have mostly been fixed in rust-lang#120584. The desugaring laid out in the RFC also added unnecessary complication to the design of the feature, and introduces its own limitations to, for example:
* Conditionally lowering to nested `impl Trait` in certain positions such as RPIT and TAIT means that we inherit the limitations of RPIT/TAIT, namely lack of support for higher-ranked opaque inference. See this code example: rust-lang#120752 (comment).
* Introducing anonymous associated types makes traits no longer object safe, since anonymous associated types are not nameable, and all associated types must be named in `dyn` types.

This last point motivates why this PR is *not* stabilizing support for associated type bounds in `dyn` types, e.g, `dyn Assoc<Item: Bound>`. Why? Because `dyn` types need to have *concrete* types for all associated items, this would necessitate a distinct lowering for associated type bounds, which seems both complicated and unnecessary compared to just requiring the user to write `impl Trait` themselves. See rust-lang#120719.

### Implementation history:

Limited to the significant behavioral changes and fixes and relevant PRs, ping me if I left something out--
* rust-lang#57428
* rust-lang#108063
* rust-lang#110512
* rust-lang#112629
* rust-lang#120719
* rust-lang#120584

Closes rust-lang#52662

[RFC 2289]: https://rust-lang.github.io/rfcs/2289-associated-type-bounds.html
…r=davidtwco

Gracefully handle `AnonConst` in `diagnostic_hir_wf_check()`

Instead of running the WF check on the `AnonConst` itself we run it on the `ty` of the generic param of which the `AnonConst` is the default value.

Fixes rust-lang#122199
misc cleanups from debugging something

rename `instantiate_canonical_with_fresh_inference_vars` to `instantiate_canonical`  the substs for the canonical are not solely infer vars as that would be wildly wrong and it is rather confusing to see this method called and think that the entire canonicalization setup is completely broken when it is not 👍

also update region debug printing to be more like the custom impls for Ty/Const, right now regions in debug output are horribly verbose and make it incredibly hard to read but with this atleast boundvars and placeholders when debugging the new solver do not take up excessive amounts of space.

r? `@lcnr`
…p_remove, r=Amanieu

Improve wording of `Vec::swap_remove`

This improve the wording for  `Vec::swap_remove`.
core: document default attribute stabilization

As of now, the first release which stabilized the `#[default]` macro for the deriving the `Default` trait for enus is not documented.
I have had to search the [`RELEASES.md`](https://github.com/rust-lang/rust/blob/master/RELEASES.md) when making sure my code would be accepted by an older Rust compiler.

I just added a line in the doc comment since, as far as I know, there's no option to pass to the `#[stable()]` attribute.

I am open to improvements in the wording.
…ls, r=compiler-errors

`NormalizesTo`: return nested goals to caller

Fixes the regression of `paperclip-core`. see https://hackmd.io/IsVAafiOTAaPIFcUxRJufw for more details.

r? `@compiler-errors`
…manieu

Fix ICE: `global_asm!()` Don't Panic When Unable to Evaluate Constant

Fixes rust-lang#121099

A bit of an inelegant fix but given that the error is created only
after call to `const_eval_poly()` and that the calling function
cannot propagate the error anywhere else, the error has to be
explicitly handled inside `mono_item.rs`.

r? `@Amanieu`
…Gomez

Fix heading anchors in doc pages.

This fixes the heading anchors on the standalone doc pages (the index, releases, etc.) so that the § symbol is only shown when the user hovers over the heading. This was changed in rust-lang#117662, but this CSS was not updated.
…jubilee

Remove redundant files, rename base riscv32 file

Fixes a mistake I made in rust-lang#117874.
… r=oli-obk

Detect allocator for box in `must_not_suspend` lint

I don't expect this to happen in practice, but better to check than not.

Fixes rust-lang#122643
@rustbot rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-release Relevant to the release subteam, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver) rollup A PR which is a rollup labels Mar 18, 2024
@workingjubilee
Copy link
Member Author

@bors r+ rollup=never p=14

@bors
Copy link
Contributor

bors commented Mar 18, 2024

📌 Commit 6380d28 has been approved by workingjubilee

It is now in the queue for this repository.

@bors bors added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Mar 18, 2024
@rust-log-analyzer
Copy link
Collaborator

The job x86_64-gnu-llvm-17 failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)
GITHUB_ACTION=__run_7
GITHUB_ACTIONS=true
GITHUB_ACTION_REF=
GITHUB_ACTION_REPOSITORY=
GITHUB_ACTOR=workingjubilee
GITHUB_API_URL=https://api.github.com
GITHUB_BASE_REF=master
GITHUB_ENV=/home/runner/work/_temp/_runner_file_commands/set_env_632fc620-8081-456e-8058-4b1824625dbc
GITHUB_EVENT_NAME=pull_request
GITHUB_EVENT_NAME=pull_request
GITHUB_EVENT_PATH=/home/runner/work/_temp/_github_workflow/event.json
GITHUB_GRAPHQL_URL=https://api.github.com/graphql
GITHUB_HEAD_REF=rollup-c3mxzrz
GITHUB_JOB=pr
GITHUB_PATH=/home/runner/work/_temp/_runner_file_commands/add_path_632fc620-8081-456e-8058-4b1824625dbc
GITHUB_REF=refs/pull/122711/merge
GITHUB_REF_NAME=122711/merge
GITHUB_REF_PROTECTED=false
---
GITHUB_SERVER_URL=https://github.com
GITHUB_SHA=fb2b4de9f9a508f6e4427b4aa296f3e46f1a3916
GITHUB_STATE=/home/runner/work/_temp/_runner_file_commands/save_state_632fc620-8081-456e-8058-4b1824625dbc
GITHUB_STEP_SUMMARY=/home/runner/work/_temp/_runner_file_commands/step_summary_632fc620-8081-456e-8058-4b1824625dbc
GITHUB_TRIGGERING_ACTOR=workingjubilee
GITHUB_WORKFLOW_REF=rust-lang/rust/.github/workflows/ci.yml@refs/pull/122711/merge
GITHUB_WORKFLOW_SHA=fb2b4de9f9a508f6e4427b4aa296f3e46f1a3916
GITHUB_WORKSPACE=/home/runner/work/rust/rust
GOROOT_1_20_X64=/opt/hostedtoolcache/go/1.20.14/x64
---
#16 exporting to docker image format
#16 sending tarball 44.8s done
#16 DONE 72.9s
##[endgroup]
Setting extra environment values for docker:  --env ENABLE_GCC_CODEGEN=1 --env GCC_EXEC_PREFIX=/usr/lib/gcc/
[CI_JOB_NAME=x86_64-gnu-llvm-17]
##[group]Clock drift check
  local time: Mon Mar 18 20:30:26 UTC 2024
  network time: Mon, 18 Mar 2024 20:30:27 GMT
  network time: Mon, 18 Mar 2024 20:30:27 GMT
##[endgroup]
sccache: Starting the server...
##[group]Configure the build
configure: processing command line
configure: 
configure: build.configure-args := ['--build=x86_64-unknown-linux-gnu', '--llvm-root=/usr/lib/llvm-17', '--enable-llvm-link-shared', '--set', 'rust.thin-lto-import-instr-limit=10', '--set', 'change-id=99999999', '--enable-verbose-configure', '--enable-sccache', '--disable-manage-submodules', '--enable-locked-deps', '--enable-cargo-native-static', '--set', 'rust.codegen-units-std=1', '--set', 'dist.compression-profile=balanced', '--dist-compression-formats=xz', '--disable-dist-src', '--release-channel=nightly', '--enable-debug-assertions', '--enable-overflow-checks', '--enable-llvm-assertions', '--set', 'rust.verify-llvm-ir', '--set', 'rust.codegen-backends=llvm,cranelift,gcc', '--set', 'llvm.static-libstdcpp', '--enable-new-symbol-mangling']
configure: target.x86_64-unknown-linux-gnu.llvm-config := /usr/lib/llvm-17/bin/llvm-config
configure: llvm.link-shared     := True
configure: rust.thin-lto-import-instr-limit := 10
configure: change-id            := 99999999
---
   Compiling rustc_resolve v0.0.0 (/checkout/compiler/rustc_resolve)
   Compiling rustc_hir_analysis v0.0.0 (/checkout/compiler/rustc_hir_analysis)
   Compiling rustc_ty_utils v0.0.0 (/checkout/compiler/rustc_ty_utils)
   Compiling rustc_mir_build v0.0.0 (/checkout/compiler/rustc_mir_build)
error[E0599]: no method named `opt_hir_node_by_def_id` found for struct `rustc_middle::ty::TyCtxt<'tcx>` in the current scope
   --> compiler/rustc_hir_analysis/src/hir_wf_check.rs:172:31
    |
172 |                     })) = tcx.opt_hir_node_by_def_id(const_param_id) =>
    |                               ^^^^^^^^^^^^^^^^^^^^^^ help: there is a method with a similar name: `hir_node_by_def_id`
For more information about this error, try `rustc --explain E0599`.
error: could not compile `rustc_hir_analysis` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
Build completed unsuccessfully in 0:02:07

@workingjubilee
Copy link
Member Author

@bors r-

@bors bors added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Mar 18, 2024
@matthiaskrgr
Copy link
Member

proly #122370

@workingjubilee workingjubilee deleted the rollup-c3mxzrz branch March 18, 2024 20:50
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rollup A PR which is a rollup S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. T-release Relevant to the release subteam, which will review and decide on the PR/issue. T-rustdoc Relevant to the rustdoc team, which will review and decide on the PR/issue. WG-trait-system-refactor The Rustc Trait System Refactor Initiative (-Znext-solver)
Projects
None yet
Development

Successfully merging this pull request may close these issues.