-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Be slightly more precise about any::type_name()'s guarantees. #71870
Conversation
This attempts to be a little clearer (including in terminology) about the lack of guarantees that any::type_name provides.
r? @kennytm (rust_highfive has picked a reviewer for you, use r? to override) |
src/libcore/any.rs
Outdated
/// `"Option<String>"` or `"std::option::Option<std::string::String>"`, but not | ||
/// `"foobar"`. In addition, the output may change between versions of the | ||
/// compiler. | ||
/// string retrned are not specified, other than being a best-effort description |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
returned
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Mea culpa! Fixed in 876001c.
@kennytm I wondered if you've had a chance to have a look at this yet? [I appreciate that I will need to, at a minimum, squash away my typo before this could be merged, but that's probably looking ahead a little too far!] |
@bors r+ rollup |
📌 Commit 003ed80 has been approved by |
… r=kennytm Be slightly more precise about any::type_name()'s guarantees. The first commit in this PR rephrases the current documentation for `any::type_name()` to be a little more specific about the guarantees (or lack thereof) that this function makes. The second commit explicitly documents that lifetimes are currently not included in the output (since this bit me particularly hard recently).
… r=kennytm Be slightly more precise about any::type_name()'s guarantees. The first commit in this PR rephrases the current documentation for `any::type_name()` to be a little more specific about the guarantees (or lack thereof) that this function makes. The second commit explicitly documents that lifetimes are currently not included in the output (since this bit me particularly hard recently).
Rollup of 12 pull requests Successful merges: - rust-lang#71525 (`prefix` should not be mutable.) - rust-lang#71741 (Pointer printing: do not print 0 offset) - rust-lang#71870 (Be slightly more precise about any::type_name()'s guarantees.) - rust-lang#71909 (Document From trait for Option implementations) - rust-lang#71964 (Fix bootstrap failing on win32) - rust-lang#72137 (Clean up E0581 explanation) - rust-lang#72138 (Add doc comment for `rustc_middle::mir::mono::Linkage`) - rust-lang#72150 (Remove UnnormalizedProjection) - rust-lang#72151 (Update books) - rust-lang#72163 (docs: remove comment referencing non-existent method) - rust-lang#72169 (Clean up E0582 explanation) - rust-lang#72183 (Fix Arc::decr_strong_count doc test) Failed merges: r? @ghost
The first commit in this PR rephrases the current documentation for
any::type_name()
to be a little more specific about the guarantees (or lack thereof) that this function makes. The second commit explicitly documents that lifetimes are currently not included in the output (since this bit me particularly hard recently).