No way to reference primitives by absolute path

[sgrif]

I got a bug report on Diesel from someone who has a database column called bool. This lead to us attempting to generate the following code:

pub struct bool;

impl QueryId for bool {
    type QueryId = Self;
    const HAS_STATIC_QUERY_ID: bool = true;
}

which causes a type mismatch because their struct is shadowing the primitive. I'd like to change the generated code to be const HAS_STATIC_QUERY_ID: ::std::bool, which is the path that the rustdoc for libstd indicates it should be, but the type doesn't exist there, or anywhere else I can find. I would assume the same issue exists for str, char, and all the numeric types.

[kennytm]

Since the std::char module already exists, the type cannot be called std::char. But it can be aliased as std::primitives::char I guess.

// in libcore or libstd:

#[allow(non_camel_case_types)]
pub mod primitives {
    mod details {
        pub type Bool = bool;
        pub type Char = char;
        // ...
    }
    pub type bool = details::Bool;
    pub type char = details::Char;
    // ...
}

[sgrif]

std::prelude::char would make sense as well

[kennytm]

Related: #32131

The reason these primitives are not put into prelude was because

Although, it's not entirely convenient to put them into prelude right now due to temporary conflicts like use prelude::v1::*; use usize; in libcore/libstd, I'd better wait for proper glob shadowing before doing it.

but I think this is no longer a problem? (cc @petrochenkov)

[petrochenkov]

Tagging this as a library issue.

The solution (if it happens on our side) is to add a module core::primitives or core::builtins (and reexport it from std as well) as described in #44865 (comment).

In the meantime Diesel can privately define such a module itself and use it when unintended shadowing can happen.

It doesn't make much sense to put primitive types into the std prelude because they are already in a prelude actually, it's just not the std prelude, but an additional language prelude one level below (as it was decided in #32131 and #32274).

[dtolnay]

I agree that primitives should be exposed at some absolute path. std::primitive sounds reasonable.

[sgrif]

@dtolnay I'd be happy to work on this. What's needed besides the implementation? I'm not entirely sure what a test for this should look like. Just a run-pass test that shadows bool and references std::primitive::bool? Do we need one for every type?

[dtolnay]

I would start with a PR that has:

• Implementation,
• Module-level documentation for std::primitive with a helpful example that communicates why you may want to use this,
• One run-pass test for a shadowed bool as you suggested.

[sgrif]

Sounds good. I'll try to get that PR done this week.

[sgrif]

Does this need a feature gate?

[dtolnay]

Yes I believe so.

[steveklabnik]

Triage: not aware of anything happening here.