f16 and f128 step 3: compiler support & feature gate by tgross35 · Pull Request #121926 · rust-lang/rust (original) (raw)
Wouldn't doing the gate in
rustc_ast_loweringrather than after resolution mean that user-defined types namedf16orf128also get flagged?User defined types will result in
Res::Def, notRes::PrimTy.
I only see Res::PrimTy being constructed once in ast_lowering at
| hir::TyKind::Path(hir::QPath::Resolved( |
|---|
| None, |
| self.arena.alloc(hir::Path { |
| res: Res::PrimTy(hir::PrimTy::Bool), |
| span, |
| segments: self.arena.alloc_from_iter([hir::PathSegment { |
| ident: Ident { name: sym::bool, span }, |
| hir_id: bool_id, |
| res: Res::PrimTy(hir::PrimTy::Bool), |
| args: None, |
| infer_args: false, |
| }]), |
| }), |
| )), |
, which looks to be for generics. The rest are in rustc_resolve/src/late.rs, which we intercept here.
Thanks for the r+. As-is should be workable for now then, I can later update this gating to your suggestion if it improves the situation with libs. I am just not exactly sure what this would look like still.