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 10 pull requests #122030

Closed
wants to merge 25 commits into from

Conversation

matthiaskrgr
Copy link
Member

Successful merges:

r? @ghost
@rustbot modify labels: rollup

Create a similar rollup

compiler-errors and others added 25 commits March 1, 2024 16:03
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
Co-authored-by: Simon Farnsworth <simon@farnz.org.uk>
They are two different ways of creating dummy results, with two
different purposes. Their implementations are separate except for
crates, where `DummyResult` depends on `DummyAstNode`.

This commit removes that dependency, so they are now fully separate. It
also expands the comment on `DummyAstNode`.
Signed-off-by: David Wood <david@davidtw.co>
This is the short description (`64-bit MinGW (Windows 7+)`) including
the platform requirements.

The reason for doing it like this is that this PR will be quite prone to
conflicts whenever targets get added, so it should be as simple as
possible to get it merged. Future PRs which migrate targets are scoped
to groups of targets, so they will not conflict as they can just touch
these.

This moves some of the information from the rustc book into the
compiler.
It cannot be queried yet, that is future work. It is also future work to
fill out all the descriptions, which will coincide with the work of
moving over existing target docs to the new format.
drop_in_place has been a lang item, not an intrinsic, for forever
Add basic i18n guidance for `Display`

I've tried to be relatively noncommittal here. The part I think is most important is to mention the concept of "display adapters" *somewhere* in the `std::fmt` documentation that has some chance of being discovered when people go looking for ways to provide context when `Display`ing their type.

Rendered:

> ### Internationalization
>
> Because a type can only have one `Display` implementation, it is often preferable to only implement `Display` when there is a single most "obvious" way that values can be formatted as text. This could mean formatting according to the "invariant" culture and "undefined" locale, or it could mean that the type display is designed for a specific culture/locale, such as developer logs.
>
> If not all values have a justifiably canonical textual format or if you want to support alternative formats not covered by the standard set of possible [formatting traits], the most flexible approach is display adapters: methods like [`str::escape_default`] or [`Path::display`] which create a wrapper implementing `Display` to output the specific display format.
>
> [formatting traits]: https://doc.rust-lang.org/nightly/std/fmt/index.html#formatting-traits
> [`str::escape_default`]: https://doc.rust-lang.org/nightly/std/primitive.str.html#method.escape_default
> [`Path::display`]: https://doc.rust-lang.org/nightly/std/path/struct.Path.html#method.display

The module docs do already have a [localization header](https://doc.rust-lang.org/nightly/std/fmt/index.html#localization), so maybe this header should be l10n instead of i18n, or maybe this information should live under that header? I'm not sure, but here on the `Display` trait at least isn't a *bad* spot to put it.

The other side of this that comes up a lot is `FromStr` compatibility, but that's for a different PR.
…r=pnkfelix

errors: share `SilentEmitter` between rustc and rustfmt

Fixes rust-lang/rustfmt#6082.

Shares the `SilentEmitter` between rustc and rustfmt, and gives it a fallback bundle (since it can emit diagnostics in some contexts).
Stop using Bubble in coherence and instead emulate it with an intercrate check

r? `@compiler-errors`

This change is kinda funny, because all I've done is reimplement `Bubble` behaviour for coherence without using `Bubble` explicitly.
…ochenkov

Dummy tweaks (attempt 2)

r? `@petrochenkov`
…iser

Add new Tier-3 target: `loongarch64-unknown-linux-musl`

MCP: rust-lang/compiler-team#518
…ature-deduction, r=oli-obk

Implement async closure signature deduction

Self-explanatory from title.

Regarding the interaction between signature deduction, fulfillment, and the new trait solver: I'm not worried about implementing closure signature deduction here because:

1. async closures are unstable, and
2. I'm reasonably confident we'll need to support signature deduction in the new solver somehow (i.e. via proof trees, which seem very promising).

This is in contrast to rust-lang#109338, which was closed because it generalizes signature deduction for a *stable* kind of expression (`async {}` blocks and `Future` traits), and which proliferated usage may pose a stabilization hazard for the new solver.

I'll be certain to make sure sure we revisit the closure signature deduction problem by the time that async closures are being stabilized (which isn't particularly soon) (edit: Put it into the async closure tracking issue). cc `@lcnr`

r? `@oli-obk`
const_eval_select: make it safe but be careful with what we expose on stable for now

As this is all still nightly-only I think `@rust-lang/wg-const-eval` can do that without involving t-lang.

r? `@oli-obk`
Cc `@Nilstrieb` -- the updated version of your RFC would basically say that we can remove these comments about not making behavior differences visible in stable `const fn`
…idtwco

Add a `description` field to target definitions

Starts addressing rust-lang#121051 (review)

This is the short description (`64-bit MinGW (Windows 7+)`) including the platform requirements.

The reason for doing it like this is that this PR will be quite prone to conflicts whenever targets get added, so it should be as simple as possible to get it merged. Future PRs which migrate targets are scoped to groups of targets, so they will not conflict as they can just touch these.

This moves some of the information from the rustc book into the compiler.
It cannot be queried yet, that is future work. It is also future work to fill out all the descriptions, which will coincide with the work of moving over existing target docs to the new format.

r? `@davidtwco` but anyone is also free to steal it
…chenkov

loongarch: add frecipe and relax target feature

This PR adds `frecipe` and `relax` target features to LoongArch:

* frecipe - Support frecipe.{s/d} and frsqrte.{s/d} instructions..
* relax - Enable Linker relaxation.
…=compiler-errors

Remove some dead code

drop_in_place has been a lang item, not an intrinsic, for forever
@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. rollup A PR which is a rollup labels Mar 5, 2024
@matthiaskrgr
Copy link
Member Author

@bors r+ rollup=never p=10

@bors
Copy link
Contributor

bors commented Mar 5, 2024

📌 Commit 6a4157b has been approved by matthiaskrgr

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 5, 2024
@rust-log-analyzer
Copy link
Collaborator

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

Click to see the possible cause of the failure (guessed by this bot)
GITHUB_ENV=/home/runner/work/_temp/_runner_file_commands/set_env_50eb9dd1-709d-4276-bd31-c8a3b0663f0c
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-t3cu537
GITHUB_JOB=pr
GITHUB_PATH=/home/runner/work/_temp/_runner_file_commands/add_path_50eb9dd1-709d-4276-bd31-c8a3b0663f0c
GITHUB_REF=refs/pull/122030/merge
GITHUB_REF_NAME=122030/merge
GITHUB_REF_PROTECTED=false
---
#12 writing image sha256:72a971782dacdbf7904577c8892274ee6f1d4f604e077aaa2e4acf0dec2c1aaf done
#12 naming to docker.io/library/rust-ci done
#12 DONE 10.0s
##[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-16]
##[group]Clock drift check
  local time: Tue Mar  5 16:37:14 UTC 2024
  network time: Tue, 05 Mar 2024 16:37:14 GMT
  network time: Tue, 05 Mar 2024 16:37:14 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-16', '--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', '--set', 'build.optimized-compiler-builtins', '--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-16/bin/llvm-config
configure: llvm.link-shared     := True
configure: rust.thin-lto-import-instr-limit := 10
configure: change-id            := 99999999

@matthiaskrgr matthiaskrgr deleted the rollup-t3cu537 branch March 16, 2024 18:19
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-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. 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.
Projects
None yet
Development

Successfully merging this pull request may close these issues.