Rollup of 6 pull requests #96877
Merged
Rollup of 6 pull requests #96877
Conversation
This file contains hidden or 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
- Refine the "NaN as a special value" top level explanation of f32 - Refine `const NAN` docstring. - Refine `fn is_sign_positive` and `fn is_sign_negative` docstrings. - Refine `fn min` and `fn max` docstrings. - Refine `fn trunc` docstrings. - Refine `fn powi` docstrings. - Refine `fn copysign` docstrings. - Reword `NaN` and `NAN` as plain "NaN", unless they refer to the specific `const NAN`. - Reword "a number" to `self` in function docstrings to clarify. - Remove "Returns NAN if the number is NAN" as this is told to be the default behavior in the top explanation. - Remove "propagating NaNs", as full propagation (preservation of payloads) is not guaranteed.
…}_{be,le,ne}_bytes
…NaN" to `max`/`min`, add disclaimer about the "propagation".
This reverts commit 4fcbc53.
PR rust-lang#96746 fixed a very similar bug, so the same logic is used in a different place.
…shtriplett Improve floating point documentation This is my attempt to improve/solve rust-lang#95468 and rust-lang#73328 . Added/refined explanations: - Refine the "NaN as a special value" top level explanation of f32 - Refine `const NAN` docstring: add an explanation about there being multitude of NaN bitpatterns and disclaimer about the portability/stability guarantees. - Refine `fn is_sign_positive` and `fn is_sign_negative` docstrings: add disclaimer about the sign bit of NaNs. - Refine `fn min` and `fn max` docstrings: explain the semantics and their relationship to the standard and libm better. - Refine `fn trunc` docstrings: explain the semantics slightly more. - Refine `fn powi` docstrings: add disclaimer that the rounding behaviour might be different from `powf`. - Refine `fn copysign` docstrings: add disclaimer about payloads of NaNs. - Refine `minimum` and `maximum`: add disclaimer that "propagating NaN" doesn't mean that propagating the NaN bit patterns is guaranteed. - Refine `max` and `min` docstrings: add "ignoring NaN" to bring the one-row explanation to parity with `minimum` and `maximum`. Cosmetic changes: - Reword `NaN` and `NAN` as plain "NaN", unless they refer to the specific `const NAN`. - Reword "a number" to `self` in function docstrings to clarify. - Remove "Returns NAN if the number is NAN" from `abs`, as this is told to be the default behavior in the top explanation.
…n-assoc-impl-items, r=lcnr Warn on unused `#[doc(hidden)]` attributes on trait impl items [Zulip conversation](https://rust-lang.zulipchat.com/#narrow/stream/266220-rustdoc/topic/.E2.9C.94.20Validy.20checks.20for.20.60.23.5Bdoc.28hidden.29.5D.60). Whether an associated item in a trait impl is shown or hidden in the documentation entirely depends on the corresponding item in the trait declaration. Rustdoc completely ignores `#[doc(hidden)]` attributes on impl items. No error or warning is emitted: ```rust pub trait Tr { fn f(); } pub struct Ty; impl Tr for Ty { #[doc(hidden)] fn f() {} } // ^^^^^^^^^^^^^^ ignored by rustdoc and currently // no error or warning issued ``` This may lead users to the wrong belief that the attribute has an effect. In fact, several such cases are found in the standard library (I've removed all of them in this PR). There does not seem to exist any incentive to allow this in the future either: Impl'ing a trait for a type means the type *fully* conforms to its API. Users can add `#[doc(hidden)]` to the whole impl if they want to hide the implementation or add the attribute to the corresponding associated item in the trait declaration to hide the specific item. Hiding an implementation of an associated item does not make much sense: The associated item can still be found on the trait page. This PR emits the warn-by-default lint `unused_attribute` for this case with a future-incompat warning. `@rustbot` label T-compiler T-rustdoc A-lint
Revert "Implement [OsStr]::join", which was merged without FCP. This reverts commit 4fcbc53, see rust-lang#96744. (I'm terribly sorry, and truly don't remember r+ing it, or even having seen it before yesterday, which is... genuinely very worrisome for me). r? `@m-ou-se`
…er-errors Actually fix ICE from rust-lang#96583 PR rust-lang#96746 fixed a very similar bug, so the same logic is used in a different place. I originally concluded that the two issues (rust-lang#96583 and rust-lang#96738) were identical by comparing the backtrace, but I didn't look close enough.
…errors Some subst cleanup Two separate things here. Both changes are useful for some refactoring I'm doing to add an "EarlyBinder" newtype. (Part of chalkification). 1) Remove `subst_spanned` and just use `subst`. It wasn't used much anyways. In practice, I think we can probably get most of the info just from the actual error message. If not, outputting logs should do the trick. (The specific line probably wouldn't help much anyways). 2) Call `.subst()` before `replace_bound_vars_with_fresh_vars` and `erase_late_bound_regions` in three places that do the opposite. I think there might have been some time in the past that the order here matter for something, but this shouldn't be the case anymore. Conceptually, it makes more sense to the of the *early bound* vars on `fn`s as "outside" the late bound vars.
…js, r=GuillaumeGomez Remove unused param from search.js::checkPath
rustbot
added
T-compiler
|
@bors r+ rollup=never p=6 |
|
📌 Commit 5972222 has been approved by |
bors
added
the
S-waiting-on-bors
|
☀️ Test successful - checks-actions |
|
Finished benchmarking commit (0dd7e10): comparison url. Summary:
If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf. Next Steps: If you can justify the regressions found in this perf run, please indicate this with @rustbot label: +perf-regression Footnotes |
|
Visiting for weekly performance triage.
@rustbot label: +perf-regression-triaged |
rustbot
added
the
perf-regression-triaged
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:
#[doc(hidden)]attributes on trait impl items #96008 (Warn on unused#[doc(hidden)]attributes on trait impl items)DefId(21:256 ~ midi_io[b6c0]::parser::midi_codec)isn't local' #96583)Failed merges:
r? @ghost
@rustbot modify labels: rollup
Create a similar rollup