StaticForeignItem and StaticItem are the same

[compiler-errors]

The struct StaticItem and StaticForeignItem are the same, so remove StaticForeignItem. Having them be separate is unique to static items -- unlike ForeignItemKind::{Fn,TyAlias}, which use the normal AST item.

r? @spastorino or @oli-obk

[rustbot]

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

[spastorino]

Yes, so I can explain a bit what's going on here. It's true these types are actually the same right now and we can totally proceed with an r+ but they shouldn't be the same and we would need to reintroduce this type later if we remove it now.

StaticForeignItem need to have safety and not expr, probably just a span.
StaticItem shouldn't have safety.

This issue was a preexisting issue before unsafe extern blocks but unsafe extern blocks make it a bit worser by needing to add yet another attribute that make these 2 types a little bit more different. But the problem is that in parsing code we convert from one type to the other just for the sake of code reuse as we parse items and foreign items with the same code and using the same type, this is why these conversions exist. We should be reusing code in a different way. I have this in my todo list and also have a branch with some changes made to disantangle a lot of that code and to make these two types different as they should be.

In any case ... feel free to do whatever you want this PR. I meant, take this as a @bors r=me if you still prefer to merge it :) or we can just close it and we can provide a proper fix to the describe issue for all this mess later.

[bors]

📌 Commit 3e59f0c has been approved by `me``

It is now in the queue for this repository.

[spastorino]

Ouch, @bors r-

[compiler-errors]

Well so here's the problem. After #124482, we now allow this code to parse:

macro_rules! s {
    ($item:item) => {}
}

s!(unsafe static FOO: usize = 1;);

I'm kind of mixed on whether that's a good thing or not, (and it should have probably been feature gated rather than silently going from fail -> pass) but we will probably need to support it when unsafe_extern_blocks is stabilized.

In that case, we need to be able to maximally parse statics with an optional safety and expr. So I don't see an obvious way to split out these two kinds of statics, at least not at the AST level, since if we remove the safety from StaticItem, then we have no way to turn a StaticItem to a ForeignStaticItem in parse_foreign_item.

[compiler-errors]

so tl;dr we need to maximally be able to parse StaticItems that are in interpolated positions behind :item macro fragment matchers so they can be expanded in extern { $item } position, which requires StaticItem to at least have a Safety, and I really don't see a benefit of making ForeignStaticItem not have an expr -- we still need to be able for this code parse, for example:

#[cfg(any())]
extern "C" {
    static FOO: usize = 1;
}

[compiler-errors]

So yeah, I don't think there's actually any splitting that's possible to be done here without regressing macro code?

@bors r=spastorino

[bors]

📌 Commit 3e59f0c has been approved by spastorino

It is now in the queue for this repository.