Separate foreign items in HIR

[nikomatsakis]

PR #37660 separates impl items from impls in the HIR for improved interaction with incremental compilation. It probably makes sense to separate foreign items in this way too -- not so much for improved incremental compilation precision, as because it makes the layout more analogous.

[nikomatsakis]

Marking this as E-mentor. I'll give a short write-up here; happy to provide a more detailed one too upon request!

The work that needs to be done is basically to model foreign items on impl items -- we would get a hir::ForeignItemRef like hir::ImplItemRef, a separate map in the Krate to store them, and modify the lowering routines analogously. Finally, there are a few places (marked with FIXMEs attached to this issue number) where we could convert to using a ItemLikeVisitor if foreign items were considered "item like".

[eddyb]

Something I've wanted to do for a while is just remove the pointless "foreign mod" nonsense in HIR.
We just need to stick the attributes from the extern {...} somewhere at the crate level or something.

[aochagavia]

For someone who has never worked on anything hir-related... Could you give examples of Rust code that compiles down to:

• An ImplItem?
• A ForeignItem?

[petrochenkov]

@aochagavia

impl Trait for Type {
    fn f() {} // <-- ImplItem
}
impl Type {
    fn g() {} // <-- ImplItem
}
extern "C" {
    fn printf(); // <-- ForeignItem
}

[aochagavia]

So an ImplItem is any item that appears within the block of an impl? And a ForeignItem is any item that appears inside an extern block? What about extern "C" fn foo() { }?

[petrochenkov]

So an ImplItem is any item that appears within the block of an impl? And a ForeignItem is any item that appears inside an extern block?

Yes.

What about extern "C" fn foo() { }?

It's just a Fn Item using non-default ABI.

[aochagavia]

Thanks!

Now some more questions, about what @eddyb said:

1. Could you give examples of Rust code that are represented as a ForeignMod? Is my interpretation below correct?

extern "C" { // <-- ForeignMod?
    fn printf(); // <-- ForeignItem
}

2. What needs to be done in order to get rid of the "pointless foreign mod nonsense"? Would you like ForeignMod to be removed? What should happen with the data then?

[petrochenkov]

Is my interpretation below correct?

Yes.

What needs to be done in order to get rid of the "pointless foreign mod nonsense"?

Suppose we have a foreign module like this:

#[link(name = "qwerty")]
extern "C" {
    fn f();
}

, then foreign items (f) need to be transplanted from the foreign module into the normal non-foreign parent module, ABI ("C") moved from the foreign module to foreign items, and attributes like #[link(name = "qwerty")] moved... somewhere.

[aochagavia]

Does that mean that ForeignMod wouldn't be needed anymore? Or are there other types of ForeignMod?

[petrochenkov]

Yeah, the whole point of this exercise is to get rid of ForeignMod (in HIR).

[eddyb]

One question is whether we might want to have a bunch of imports that share some common information - AFAIK all the attributes on an extern "ABI" {...} don't affect the imports inside but rather the crate.

cc @retep998