[Tess4552]

Adds intrinsics and methods to get the raw doc comment strings from adts, fields, and variants. As noted in the tracking issue #146922, before stabilizing the interface we should consider whether these methods get the raw strings.

r? @oli-obk

[rustbot]

Some changes occurred to the CTFE machinery

cc @RalfJung, @oli-obk, @lcnr

The reflection data structures are tied exactly to the implementation
in the compiler. Make sure to also adjust rustc_const_eval/src/const_eval/type_info.rs

cc @oli-obk

Some changes occurred to the intrinsics. Make sure the CTFE / Miri interpreter
gets adapted for the changes, if necessary.

cc @rust-lang/miri, @RalfJung, @oli-obk, @lcnr

[RalfJung]

The list of intrinsics here is growing so much that I think it'd make sense to move it to a separate file. (In a separate PR.)

View changes since the review

[oli-obk]

Maybe we should add a variant-pattern type (similar to what we do with FRTs instead of also having a field variant of many intrinsics) sooner rather than later instead of having to have all these intrinsics duplicated for variants and for normal types. Not for this PR, but just adding them to the type system without exposing them at the AST level shouldn't be too hard (famous last words)

View changes since the review

[rustbot]

Reminder, once the PR becomes ready for a review, use @rustbot ready.

[oli-obk]

@bors r+ rollup

View changes since this review

[rust-bors]

📌 Commit b6997cd has been tentatively approved by oli-obk

It will be put into the queue for this repository once PR CI succeeds.

[JonathanBrouwer]

💔 I suspect this PR failed tests as part of a rollup
@bors r-

After fixing the problem, consider running a try job for the failed job before re-approving.

Link to failure: #165134 (comment)

Soft conflict with #165079, please wait for that to merge then rebase

[rust-bors]

This pull request was unapproved.

This PR was contained in a rollup (#165134), which was unapproved.

View changes since this unapproval

[mejrs]

Is it sound for doc comments to end up in the type system?

View changes since this review

[mejrs]

Can you also update the comment here (assuming this is intended to work cross crate)

rust/compiler/rustc_metadata/src/rmeta/encoder.rs

Lines 952 to 958 in 2687a50

	} else if let rustc_attr_ir::Attribute::Parsed(AttributeKind::DocComment { .. }) = attr {
	// We keep all doc comments reachable to rustdoc because they might be "imported" into
	// downstream crates if they use `#[doc(inline)]` to copy an item's documentation into
	// their own.
	if state.is_exported {
	should_encode = true;
	}

[Tess4552]

Thanks for the suggestions, incorporated them.

Regarding the soundness of having doc comments in the type system, I think @yara-blue can provide more insight in it.

@rustbot ready

[yara-blue]

Is it sound for doc comments to end up in the type system?

Are you concerned about semver? It is a wider concern within reflection we have some solutions in mind, ill expand on those later once they are worked out a bit more.

[mejrs]

Sorry for being a bit vague earlier, I didn't have the time to properly investigate and come up with an example.

We do not always keep doc comments around (see encoder.rs above), so different crates might disagree on whether something has doc comments or not. This api allows that disagreement to end up in the type system, which is unsound.

To illustrate, the following snippet has undefined behavior:

// crate `dep`
#![feature(type_info)]

use std::any::TypeId;

pub const N: usize = {
    struct TestStruct {
        /// 🦀
        field: u8,
    }
    let ty_id = TypeId::of::<TestStruct>();
    ty_id.field(0, 0).docs().len()
};

pub fn get_n() -> usize {
    N
}

pub fn unpack(x: [String; N]) -> String {
    let [s] = x;
    s
}

fn main(){
    println!("{}, {}", dep::N, dep::get_n()); // 0, 1

    let x = [String::new(); dep::N];
    let x = dep::unpack(x);
    println!("{}", x); 
}

[Tess4552]

Think that makes sense. Will take look when I have more time later next week.

@rustbot author

[yara-blue]

We do not always keep doc comments around (see encoder.rs above), so different crates might disagree on whether something has doc comments or not. This api allows that disagreement to end up in the type system, which is unsound.

ahh I get it, thats a problem indeed. Will run into the same with other attributes as well. Thanks for that clear example! We should adopt it as a test.

[mejrs]

I think just always encoding doc comments is the easiest fix, if perf allows it (perf run at #165304). Alternatives include maybe some way to mark things as "effectively visible" if their type info is used. Or maybe docs ought to return some opaque type with non const methods so it can be returned from comptime fn but not used within it.

[rust-bors]

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