-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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 9 pull requests #122045
Rollup of 9 pull requests #122045
Conversation
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`.
Modified according to rust-lang/compiler-team#505.
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.
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`````
…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`
…l_20240304, r=lcnr Change some attributes to only_local. Modified according to rust-lang/compiler-team#505. r? ``@lcnr``
will_wake tests fail on Miri and that is expected Follow-up to rust-lang#121622 r? ```@cuviper``` ```@dtolnay```
only set noalias on Box with the global allocator As discovered in rust-lang/miri#3341, `noalias` and custom allocators don't go well together. rustc can now check whether a Box uses the global allocator. This replaces the previous ad-hoc and rather unprincipled check for a zero-sized allocator. This is the rustc part of fixing that; Miri will also need a patch.
…=compiler-errors Remove some dead code drop_in_place has been a lang item, not an intrinsic, for forever
@bors r+ rollup=never p=9 |
…iaskrgr Rollup of 9 pull requests Successful merges: - rust-lang#121065 (Add basic i18n guidance for `Display`) - rust-lang#121744 (Stop using Bubble in coherence and instead emulate it with an intercrate check) - rust-lang#121829 (Dummy tweaks (attempt 2)) - rust-lang#121857 (Implement async closure signature deduction) - rust-lang#121894 (const_eval_select: make it safe but be careful with what we expose on stable for now) - rust-lang#122014 (Change some attributes to only_local.) - rust-lang#122016 (will_wake tests fail on Miri and that is expected) - rust-lang#122018 (only set noalias on Box with the global allocator) - rust-lang#122028 (Remove some dead code) r? `@ghost` `@rustbot` modify labels: rollup
The job Click to see the possible cause of the failure (guessed by this bot)
|
💔 Test failed - checks-actions |
@bors retry |
☀️ Test successful - checks-actions |
📌 Perf builds for each rolled up PR:
previous master: 62415e2a95 In the case of a perf regression, run the following command for each PR you suspect might be the cause: |
Finished benchmarking commit (b77e018): comparison URL. Overall result: ❌ regressions - no action needed@rustbot label: -perf-regression Instruction countThis is a highly reliable metric that was used to determine the overall result at the top of this comment.
Max RSS (memory usage)ResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
CyclesResultsThis is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.
Binary sizeThis benchmark run did not return any relevant results for this metric. Bootstrap: 645.485s -> 646.106s (0.10%) |
Successful merges:
Display
#121065 (Add basic i18n guidance forDisplay
)r? @ghost
@rustbot modify labels: rollup
Create a similar rollup