Use associated numeric consts in documentation #69860
Merged
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
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
sfackler
reviewed
Mar 9, 2020
|
The job Click to expand the log.I'm a bot! I can only do what humans tell me to, so if this was not helpful or you have suggestions for improvements, please ping or otherwise contact |
JohnTitor
added
the
S-waiting-on-author
|
☔ The latest upstream changes (presumably #70132) made this pull request unmergeable. Please resolve the merge conflicts. |
faern
force-pushed
the
use-assoc-int-consts
branch
from
c548bf7 to
603f313
Compare
faern
changed the title
|
I made this PR smaller and only focus on the most important parts: Documentation. Showing users the recommended way to write new code. Updating internal usage of the old way of reaching the constants can be done later. The important part is that we are consistent and up to date when users read documentation to try to learn how to do stuff. There is a separate PR on the stdarch repo (rust-lang/stdarch#843) which I bump in this PR. Please tell me if this is not the correct procedure to get a submodule updated here. |
|
☔ The latest upstream changes (presumably #70525) made this pull request unmergeable. Please resolve the merge conflicts. |
faern
force-pushed
the
use-assoc-int-consts
branch
from
603f313 to
9962fe3
Compare
|
Fixed the conflict and dropping the bump in |
|
☔ The latest upstream changes (presumably #70722) made this pull request unmergeable. Please resolve the merge conflicts. |
faern
force-pushed
the
use-assoc-int-consts
branch
from
9962fe3 to
c831265
Compare
|
Seems like I can't do that... Anyway, it would be awesome to get a small docs PR merged before something else collides with it again. The closer to stabilization of the feature we can make the docs up to date the better. @sfackler |
|
@bors r+ |
|
📌 Commit c831265 has been approved by |
bors
added
S-waiting-on-bors
|
I would also be happy to accept the non-doc cases of this in a separate PR. |
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
Apr 3, 2020
Use associated numeric consts in documentation Now when the associated constants on int/float types are stabilized and the recommended way of accessing said constants (rust-lang#68952). We can start using it in this repository, and recommend it via documentation example code. This PR is the reincarnation of rust-lang#67913 minus the actual adding + stabilization of said constants. (EDIT: Now it's only changing the documentation. So users will see the new consts, but we don't yet update the internal code) Because of how fast bit rot happens to PRs that touch this many files, it does not try to replace 100% of the old usage of the constants in the entire repo, but a good chunk of them.
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Apr 3, 2020
Rollup of 9 pull requests Successful merges: - rust-lang#69860 (Use associated numeric consts in documentation) - rust-lang#70576 (Update the description of the ticket to point at RFC 1721) - rust-lang#70597 (Fix double-free and undefined behaviour in libstd::syn::unix::Thread::new) - rust-lang#70640 (Hide `task_context` when lowering body) - rust-lang#70641 (Remove duplicated code in trait selection) - rust-lang#70707 (Remove unused graphviz emitter) - rust-lang#70720 (Place TLS initializers with relocations in .tdata) - rust-lang#70735 (Clean up E0502 explanation) - rust-lang#70741 (Add test for rust-lang#59023) Failed merges: r? @ghost
This was referenced Apr 4, 2020
Dylan-DPC-zz
pushed a commit
to Dylan-DPC-zz/rust
that referenced
this pull request
Apr 5, 2020
Don't import integer and float modules, use assoc consts Stop importing the standard library integer and float modules to reach the `MIN`, `MAX` and other constants. They are available directly on the primitive types now. This PR is a follow up of rust-lang#69860 which made sure we use the new constants in documentation. This type of change touches a lot of files, and previously all my assoc int consts PRs had collisions and were accepted only after a long delay. So I'd prefer to do it in smaller steps now. Just removing these imports seem like a good next step. r? @dtolnay
Centril
added a commit
to Centril/rust
that referenced
this pull request
Apr 5, 2020
…lnay Stop importing the float modules in documentation Follow up to rust-lang#69860. I realized I had not searched for and fixed this for the float values. So with this PR they also use the associated constants instead of the module level constants. For the documentation where it also was using the `consts` submodule I opted to change it to import that directly. This becomes more in line with how other docs that use the `consts` submodule looks. And it also makes it so there are not two `f32` or `f64` things in the current namespace (both the module and the primitive type) and then hopefully confusing documentation readers less. r? @dtolnay
bors
added a commit
to rust-lang/rust-clippy
that referenced
this pull request
Apr 8, 2020
Use assoc int and float consts instead of module level ones changelog: Recommend primitive type associated constants instead of module level constants In Rust 1.43 integer and float primitive types will have a number of new associated constants. For example `MAX`, `MIN` and a number of constants related to the machine representation of floats. rust-lang/rust#68952 These new constants are preferred over the module level constants in `{core,std}::{f*, u*, i*}`. I have in the last few days made sure that the documentation in the main rust repository uses the new constants in every place I could find (rust-lang/rust#69860, rust-lang/rust#70782). So the next step is naturally to make the linter recommend the new constants as well. This PR only changes two lints. There are more. But I did not want the PR to be too big. And since I have not contributed to clippy before it felt saner to start with a small PR so I see if there are any quirks. More will come later.
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.
Now when the associated constants on int/float types are stabilized and the recommended way of accessing said constants (#68952). We can start using it in this repository, and recommend it via documentation example code.
This PR is the reincarnation of #67913 minus the actual adding + stabilization of said constants. (EDIT: Now it's only changing the documentation. So users will see the new consts, but we don't yet update the internal code)
Because of how fast bit rot happens to PRs that touch this many files, it does not try to replace 100% of the old usage of the constants in the entire repo, but a good chunk of them.