Rollup of 9 pull requests #122032
Closed
Rollup of 9 pull requests #122032
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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
…=compiler-errors Remove some dead code drop_in_place has been a lang item, not an intrinsic, for forever
rustbot
added
S-waiting-on-review
|
@bors r+ rollup=never p=11 |
bors
removed
the
S-waiting-on-review
bors
added
the
S-waiting-on-bors
|
The job Click to see the possible cause of the failure (guessed by this bot) |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Successful merges:
Display#121065 (Add basic i18n guidance forDisplay)SilentEmitterbetween rustc and rustfmt #121301 (errors: shareSilentEmitterbetween rustc and rustfmt)loongarch64-unknown-linux-musl#121832 (Add new Tier-3 target:loongarch64-unknown-linux-musl)descriptionfield to target definitions #121905 (Add adescriptionfield to target definitions)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup