about summary refs log tree commit diff
path: root/library/core/src/any.rs
AgeCommit message (Collapse)AuthorLines
2025-09-26Update CURRENT_RUSTC_VERSION post-bumpMark Rousskov-1/+1
2025-09-12Constify Eq, Ord, PartialOrdEvgenii Zheltonozhskii-1/+2
2025-08-14Print regions in `type_name`.Nicholas Nethercote-3/+3
Currently they are skipped, which is a bit weird, and it sometimes causes malformed output like `Foo<>` and `dyn Bar<, A = u32>`. Most regions are erased by the time `type_name` does its work. So all regions are now printed as `'_` in non-optional places. Not perfect, but better than the status quo. `c_name` is updated to trim lifetimes from MIR pass names, so that the `PASS_NAMES` sanity check still works. It is also renamed as `simplify_pass_type_name` and made non-const, because it doesn't need to be const and the non-const implementation is much shorter. The commit also renames `should_print_region` as `should_print_optional_region`, which makes it clearer that it only applies to some regions. Fixes #145168.
2025-07-21Stabilize const `TypeId::of`Oli Scherer-2/+2
2025-07-19interpret: fix TypeId pointers being considered data pointersRalf Jung-1/+1
2025-07-09Add opaque TypeId handles for CTFEOli Scherer-27/+57
2025-06-30Stop backends from needing to support nullary intrinsicsOli Scherer-2/+2
2025-04-16fix missing word in commentKent Ross-2/+2
2025-03-06Remove #[cfg(not(test))] gates in coreThalia Archibald-1/+1
These gates are unnecessary now that unit tests for `core` are in a separate package, `coretests`, instead of in the same files as the source code. They previously prevented the two `core` versions from conflicting with each other.
2025-02-21Rollup merge of #136148 - kpreid:type-str, r=joboetMatthias Krüger-3/+17
Optionally add type names to `TypeId`s. This feature is intended to provide expensive but thorough help for developers who have an unexpected `TypeId` value and need to determine what type it actually is. It causes `impl Debug for TypeId` to print the type name in addition to the opaque ID hash, and in order to do so, adds a name field to `TypeId`. The cost of this is the increased size of `TypeId` and the need to store type names in the binary; therefore, it is an optional feature. It does not expose any new public API, only change the `Debug` implementation. It may be enabled via `cargo -Zbuild-std -Zbuild-std-features=debug_typeid`. (Note that `-Zbuild-std-features` disables default features which you may wish to reenable in addition; see <https://doc.rust-lang.org/cargo/reference/unstable.html#build-std-features>.) Example usage and output: ``` fn main() { use std::any::{Any, TypeId}; dbg!(TypeId::of::<usize>(), drop::<usize>.type_id()); } ``` ``` TypeId::of::<usize>() = TypeId(0x763d199bccd319899208909ed1a860c6 = usize) drop::<usize>.type_id() = TypeId(0xe6a34bd13f8c92dd47806da07b8cca9a = core::mem::drop<usize>) ``` Also added feature declarations for the existing `debug_refcell` feature so it is usable from the `rust.std-features` option of `config.toml`. Related issues: * #68379 * #61533
2025-02-11Optionally add type names to `TypeId`s.Kevin Reid-3/+17
This feature is intended to provide expensive but thorough help for developers who have an unexpected `TypeId` value and need to determine what type it actually is. It causes `impl Debug for TypeId` to print the type name in addition to the opaque ID hash, and in order to do so, adds a name field to `TypeId`. The cost of this is the increased size of `TypeId` and the need to store type names in the binary; therefore, it is an optional feature. It may be enabled via `cargo -Zbuild-std -Zbuild-std-features=debug_typeid`. (Note that `-Zbuild-std-features` disables default features which you may wish to reenable in addition; see <https://doc.rust-lang.org/cargo/reference/unstable.html#build-std-features>.) Example usage and output: ``` fn main() { use std::any::{Any, TypeId}; dbg!(TypeId::of::<usize>(), drop::<usize>.type_id()); } ``` ``` TypeId::of::<usize>() = TypeId(0x763d199bccd319899208909ed1a860c6 = usize) drop::<usize>.type_id() = TypeId(0xe6a34bd13f8c92dd47806da07b8cca9a = core::mem::drop<usize>) ``` Also added feature declarations for the existing `debug_refcell` feature so it is usable from the `rust.std-features` option of `config.toml`.
2025-02-11include note on variance and exampleMarijn Schouten-2/+96
Fixes #89150 Co-authored-by: Daniel Henry-Mantilla <daniel.henry.mantilla@gmail.com>
2024-12-22Fixes safety docs for `dyn Any + Send {+ Sync}`Mostafa Khaled-2/+12
2024-07-29Reformat `use` declarations.Nicholas Nethercote-3/+1
The previous commit updated `rustfmt.toml` appropriately. This commit is the outcome of running `x fmt --all` with the new formatting options.
2024-06-30Print `TypeId` as hex for debuggingTrevor Gross-1/+1
In <https://github.com/rust-lang/rust/pull/127134>, the `Debug` impl for `TypeId` was changed to print a single integer rather than a tuple. Change this again to print as hex for more concise and consistent formatting, as was suggested. Result: TypeId(0x1378bb1c0a0202683eb65e7c11f2e4d7)
2024-06-29Print `TypeId` as a `u128` for `Debug`Trevor Gross-1/+12
Since <https://github.com/rust-lang/rust/pull/121358>, `TypeId` is represented as a `(u64, u64)`. This also made the debug implementation a lot larger, which is especially apparent with pretty formatting. Make this less noisy by converting the inner value back to a `u128` then printing as a tuple struct. Current: TypeId { t: (1403077013027291752, 4518903163082958039) } TypeId { t: ( 1403077013027291752, 4518903163082958039, ), } New: TypeId(25882202575019293479932656973818029271) TypeId( 25882202575019293479932656973818029271, )
2024-03-29Improve wording in std::any explanationWilfred Hughes-4/+4
Prefer 'log' over 'log out' to avoid confusion, and use backticks consistently.
2024-02-25Fix Hash implDavid Thomas-1/+1
2024-02-20Add extra detail to field commentGnome!-1/+2
Co-authored-by: Nilstrieb <48135649+Nilstrieb@users.noreply.github.com>
2024-02-20Reduce alignment of TypeId to u64 alignmentGnomedDev-3/+7
2023-12-22update version placeholdersPietro Albini-1/+1
2023-12-15Rollup merge of #118234 - tgross35:type_name_of_value, r=dtolnayMatthias Krüger-21/+18
Stabilize `type_name_of_val` Make the following API stable: ```rust // in core::any pub fn type_name_of_val<T: ?Sized>(_val: &T) -> &'static str ``` This is a convenience method to get the type name of a value, as opposed to `type_name` that takes a type as a generic. Const stability is not added because this relies on `type_name` which is also not const. That has a blocking issue https://github.com/rust-lang/rust/issues/97156. Wording was also changed to direct most of the details to `type_name` so we don't have as much duplicated documentation. Fixes tracking issue #66359. There were two main concerns in the tracking issue: 1. Naming: `type_name_of` and `type_name_of_val` seem like the only mentioned options. Differences in opinion here come from `std::mem::{size_of, align_of, size_of_val, align_of_val}`. This PR leaves the name as `type_name_of_val`, but I can change if desired since it is pretty verbose. 2. What this displays for `&dyn`: I don't think that having `type_name_of_val` function resolve those is worth the headache it would be, see https://github.com/rust-lang/rust/issues/66359#issuecomment-1718480774 for some workarounds. I also amended the docs wording to leave it open-ended, in case we have means to change that behavior in the future. ``@rustbot`` label -T-libs +T-libs-api +needs-fcp r? libs-api
2023-12-05Stabilize `type_name_of_val`Trevor Gross-21/+18
Make the following API stable: // in core::any pub fn type_name_of_val<T: ?Sized>(_val: &T) -> &'static str Const stability is not added because this relies on `type_name` which is also not const. That has a blocking issue. Fixes #66359
2023-11-17Document behavior of `<dyn Any as Any>::type_id()`Jules Bertholet-0/+5
See also #57893
2023-08-13core/any: remove Provider traitwayne warren-587/+0
* remove `impl Provider for Error` * rename `Demand` to `Request` * update docstrings to focus on the conceptual API provided by `Request` * move `core::any::{request_ref, request_value}` functions into `core::error` * move `core::any::tag`, `core::any::Request`, an `core::any::TaggedOption` into `core::error` * replace `provide_any` feature name w/ `error_generic_member_access` * move `core::error::request_{ref,value} tests into core::tests::error module * update unit and doc tests
2023-07-12Flip cfg's for bootstrap bumpMark Rousskov-3/+0
2023-06-07Fix typoThom Chiovoloni-1/+1
Co-authored-by: bjorn3 <17426603+bjorn3@users.noreply.github.com>
2023-06-04Use 128 bits for TypeId hashThom Chiovoloni-3/+28
- Switch TypeId to 128 bits - Hack around the fact that tracing-subscriber dislikes how TypeId is hashed - Remove lowering of type_id128 from rustc_codegen_llvm - Remove unnecessary `type_id128` intrinsic (just change return type of `type_id`) - Only hash the lower 64 bits of the TypeId - Reword comment
2023-05-25Remove structural match from `TypeId`.raldone01-1/+9
2023-05-16Hide repr attribute from doc of types without guaranteed reprDavid Tolnay-1/+1
2023-04-16rm const traits in libcoreDeadbeef-2/+1
2023-03-03Match unmatched backticks in library/est31-1/+1
2023-01-16Constify `TypeId` ordering implsonestacked-1/+2
2022-12-27Fix `core::any` mod-level docsAlbert Larsan-1/+1
2022-08-23Add `Provider::{would_be_satisfied_by_value_of,would_be_satisfied_by_ref_of}`Jake Goulding-0/+165
While the `provide_*` methods already short-circuit when a value has been provided, there are times where an expensive computation is needed to determine if the `provide_*` method can even be called.
2022-08-23Support eager and lazy methods for providing references and valuesJake Goulding-6/+68
There are times where computing a value may be cheap, or where computing a reference may be expensive, so this fills out the possibilities.
2022-08-20Improve primitive/std docs separation and headersCameron Steffen-4/+1
2022-07-05core::any: replace some unstable generic types with impl TraitNick Cameron-20/+15
Signed-off-by: Nick Cameron <nrc@ncameron.org>
2022-06-10Fix typos in Provider API docsBenjamin Herr-2/+2
2022-06-06Address reviewer commentsNick Cameron-18/+37
Signed-off-by: Nick Cameron <nrc@ncameron.org>
2022-06-06Add tracking issue numberNick Cameron-8/+8
Signed-off-by: Nick Cameron <nrc@ncameron.org>
2022-06-06Add examples to docsNick Cameron-2/+76
Signed-off-by: Nick Cameron <nrc@ncameron.org>
2022-06-06Update docsNick Cameron-19/+22
Signed-off-by: Nick Cameron <nrc@ncameron.org>
2022-06-06Modify the signature of the request_* methods so that trait_upcasting is not ↵Nick Cameron-9/+16
required Signed-off-by: Nick Cameron <nrc@ncameron.org>
2022-06-06Add the Provider api to core::anyNick Cameron-3/+270
Signed-off-by: Nick Cameron <nrc@ncameron.org>
2022-03-10Use implicit capture syntax in format_argsT-O-R-U-S-1/+1
This updates the standard library's documentation to use the new syntax. The documentation is worthwhile to update as it should be more idiomatic (particularly for features like this, which are nice for users to get acquainted with). The general codebase is likely more hassle than benefit to update: it'll hurt git blame, and generally updates can be done by folks updating the code if (and when) that makes things more readable with the new format. A few places in the compiler and library code are updated (mostly just due to already having been done when this commit was first authored).
2021-12-26Reverts #92135 because perf regressionAngelicosPhosphoros-1/+0
2021-12-20Add `#[inline]` modifier to `TypeId::of`AngelicosPhosphoros-0/+1
It was already inlined but it happened only in 4th InlinerPass on my testcase. With `#[inline]` modifier it happens on 2nd pass. Closes #74362
2021-11-20fix doc links for `downcast_unchecked`Ibraheem Ahmed-4/+0
2021-11-12add tracking issue for `downcast_unchecked`Ibraheem Ahmed-6/+6
generated by cgit-pink 1.4.1-3-g733a5 (git 2.37.1) at 2026-02-28 21:20:50 +0000