Reword trivial_casts lint in rustc book to better explain what it does.#76555
Merged
bors merged 1 commit intorust-lang:masterfrom Sep 10, 2020
alilleybrinker:reword_trivial_casts_lint_doc
Merged
Reword trivial_casts lint in rustc book to better explain what it does.#76555bors merged 1 commit intorust-lang:masterfrom alilleybrinker:reword_trivial_casts_lint_doc
trivial_casts lint in rustc book to better explain what it does.#76555bors merged 1 commit intorust-lang:masterfrom
alilleybrinker:reword_trivial_casts_lint_doc
Conversation
The current description of the trivial casts lint under the "allowed by default" listing in the rustc book indicates the lint is for lints which may be removed, which is less clear than saying it's for lints which may be replaced by coercion (which is the wording used by the error message included in the doc). This commit changes the wording slightly to better describe what the lint does.
Contributor
|
(rust_highfive has picked a reviewer for you, use r? to override) |
trivial_casts lint to better explain what it does.trivial_casts lint in rustc book to better explain what it does.
Contributor
|
@bors: r+ rollup thank you! |
Collaborator
|
📌 Commit 01bf350 has been approved by |
bors
added a commit
to rust-lang-ci/rust
that referenced
this pull request
Sep 10, 2020
Rollup of 11 pull requests Successful merges: - rust-lang#75857 (Syntactically permit unsafety on mods) - rust-lang#76289 (Add docs about crate level documentation support) - rust-lang#76514 (Add revisions to const generic issue UI tests.) - rust-lang#76524 (typeck: don't suggest inaccessible private fields) - rust-lang#76548 (Validate removal of AscribeUserType, FakeRead, and Shallow borrow) - rust-lang#76555 (Reword `trivial_casts` lint in rustc book to better explain what it does.) - rust-lang#76559 (add the `const_evaluatable_checked` feature) - rust-lang#76563 (small typo fix in rustc_parse docs) - rust-lang#76565 (take reference to Place directly instead of taking reference to Box<Place>) - rust-lang#76567 (use push(char) to add chars (single-char &strs) to strings instead of push_str(&str)) - rust-lang#76568 (Add missing examples on core traits' method) Failed merges: r? `@ghost`
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
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.
The current description of the trivial casts lint under the "allowed
by default" listing in the rustc book indicates the lint is for casts
which may be removed, which is less clear than saying it's for casts
which may be replaced by coercion (which is the wording used by the
error message included in the doc).
This commit changes the wording slightly to better describe what the
lint does.
This issue bit me in some recent code where I was attempting to
convert a
Vec<SomeType>to aVec<SomeTraitObject>, andhit my project-wide
#![deny(trivial_casts)]withmap(|o| Box::new(o) as TraitObject). I'd read the book docs fortrivial_castsand was surprised by the error, as I took it to meanthe cast ought to be removed (rather than replaced by ascription
in this case). Removing the cast meant other code didn't compile,
and I then found issues like #23742 and realized my misunderstanding.