Skip to content

Conversation

@SpriteOvO
Copy link
Member

@SpriteOvO SpriteOvO commented Jan 14, 2026

Tracking issue: #146922 #![feature(type_info)]

This PR supports ADT types for feature type_info reflection.
(It's still a draft PR, with implementation in progress)

Note that this PR does not take SemVer into consideration (I left a FIXME comment). As discussed earlier (comment), this requires further discussion. However, I hope we could get an initial implementation to land first, so we can start playing with it.

Progress / Checklist

r? @oli-obk

Support {bool,char,int,uint,float,str} primitive types for feature
`type_info` reflection.
@SpriteOvO SpriteOvO added A-type-system Area: Type system F-type_info #![feature(type_info)] labels Jan 14, 2026
@rustbot rustbot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Jan 14, 2026
@rustbot
Copy link
Collaborator

rustbot commented Jan 14, 2026

oli-obk is not on the review rotation at the moment.
They may take a while to respond.

@SpriteOvO SpriteOvO changed the title Support primitives in type info reflection Support ADT types in type info reflection Jan 14, 2026
Comment on lines +236 to +245
sym::name => {
if let Some(name) = name {
let name_place = self.allocate_str_dedup(name.as_str())?;
let ptr = self.mplace_to_ref(&name_place)?;
self.write_immediate(*ptr, &field_place)?
} else {
let (variant, _) = self.downcast(&field_place, sym::None)?;
self.write_discriminant(variant, &field_place)?;
}
}
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I feel like I should write sym::Some discriminant for name? 🤔 Writing ptr directly seems to work, but this relies on how Option<&'static str> is underlyingly represented IIUC.

But const eval interpreter doesn't complain about this -- perhaps it should?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the interpreter doesn't care if the value is exactly the same as if it had its discriminant written. There is some talk about SetDiscriminant needing to happen always, but it's not really important for us here, this will be fixed by whoever changes it

also irrelevant if we make the field just always have a name (rendering the index)

@rust-log-analyzer
Copy link
Collaborator

The job aarch64-gnu-llvm-20-2 failed! Check out the build log: (web) (plain enhanced) (plain)

Click to see the possible cause of the failure (guessed by this bot)
fmt: checked 6650 files
tidy check
tidy [rustdoc_json (src)]: `rustdoc-json-types` modified, checking format version
tidy: Skipping binary file check, read-only filesystem
tidy [style (compiler)]: /checkout/compiler/rustc_const_eval/src/const_eval/type_info.rs:77: TODO is used for tasks that should be done before merging a PR; If you want to leave a message in the codebase use FIXME
tidy [style (compiler)]: /checkout/compiler/rustc_const_eval/src/const_eval/type_info.rs:354: TODO is used for tasks that should be done before merging a PR; If you want to leave a message in the codebase use FIXME
tidy [style (compiler)]: FAIL
tidy [alphabetical (compiler)]: /checkout/compiler/rustc_span/src/symbol.rs:1081: line not in alphabetical order (tip: use --bless to sort this list)
tidy [alphabetical (compiler)]: FAIL
tidy: The following checks failed: alphabetical (compiler), style (compiler)
Bootstrap failed while executing `--stage 2 test --skip tests --skip coverage-map --skip coverage-run --skip library --skip tidyselftest`
Command `/checkout/obj/build/aarch64-unknown-linux-gnu/stage1-tools-bin/rust-tidy /checkout /checkout/obj/build/aarch64-unknown-linux-gnu/stage0/bin/cargo /checkout/obj/build 4 yarn` failed with exit code 1
Created at: src/bootstrap/src/core/build_steps/tool.rs:1612:23
Executed at: src/bootstrap/src/core/build_steps/test.rs:1357:29

Command has failed. Rerun with -v to see more details.
Build completed unsuccessfully in 0:00:52
  local time: Wed Jan 14 21:40:41 UTC 2026
  network time: Wed, 14 Jan 2026 21:40:42 GMT
##[error]Process completed with exit code 1.
##[group]Run echo "disk usage:"

#[non_exhaustive]
#[unstable(feature = "type_info", issue = "146922")]
pub struct Field {
/// The name of the struct.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the field's name

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

could also make it non-optional and produce integer names for tuples and tuple structs

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh that was a typo.

could also make it non-optional and produce integer names for tuples and tuple structs

Good idea.

Comment on lines +236 to +245
sym::name => {
if let Some(name) = name {
let name_place = self.allocate_str_dedup(name.as_str())?;
let ptr = self.mplace_to_ref(&name_place)?;
self.write_immediate(*ptr, &field_place)?
} else {
let (variant, _) = self.downcast(&field_place, sym::None)?;
self.write_discriminant(variant, &field_place)?;
}
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the interpreter doesn't care if the value is exactly the same as if it had its discriminant written. There is some talk about SetDiscriminant needing to happen always, but it's not really important for us here, this will be fixed by whoever changes it

also irrelevant if we make the field just always have a name (rendering the index)

@rust-bors
Copy link
Contributor

rust-bors bot commented Jan 16, 2026

☔ The latest upstream changes (presumably #151210) made this pull request unmergeable. Please resolve the merge conflicts.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

A-type-system Area: Type system F-type_info #![feature(type_info)] S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-libs Relevant to the library team, which will review and decide on the PR/issue.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants