-
Notifications
You must be signed in to change notification settings - Fork 12.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Resolve lang items in AST #103662
Resolve lang items in AST #103662
Conversation
r? @TaKO8Ki (rustbot has picked a reviewer for you, use r? to override) |
cc @davidtwco, @compiler-errors, @JohnTitor, @estebank, @TaKO8Ki Some changes occurred in src/tools/clippy cc @rust-lang/clippy Some changes occurred in need_type_info.rs cc @lcnr |
This comment has been minimized.
This comment has been minimized.
This comment was marked as resolved.
This comment was marked as resolved.
This comment has been minimized.
This comment has been minimized.
Changed the self-type path segment to a dummy segment ( |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
9d50f27
to
141d06a
Compare
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Hey! It looks like you've submitted a new PR for the library teams! If this PR contains changes to any Examples of
|
@rustbot ready (sorry for the false alarm earlier) |
☔ The latest upstream changes (presumably #103888) made this pull request unmergeable. Please resolve the merge conflicts. |
|
||
pub fn generics(&self) -> Option<&Generics> { | ||
match self { | ||
Self::Const(..) => None, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Self::Const(..) => None, | |
AssocItemKind::Const(..) => None, |
Could you avoid using Self
outside of generic contexts, it makes it harder to search and read code.
@@ -0,0 +1,126 @@ | |||
use crate::errors::{ | |||
IncorrectTarget, LangItemOnIncorrectTarget, UnknownExternLangItem, UnknownLangItem, | |||
}; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: could you split imports so they fit on a single line?
visit::walk_crate(&mut collector, krate); | ||
let LanguageItemCollector { items, missing, .. } = collector; | ||
self.lang_items = items; | ||
self.missing_lang_items = missing; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You could keep a mutable reference to Resolver
and push directly to resolver.items
/resolver.missing
instead of keeping temporary copies.
@@ -955,6 +957,8 @@ pub struct Resolver<'a> { | |||
/// the surface (`macro` items in libcore), but are actually attributes or derives. | |||
builtin_macro_kinds: FxHashMap<LocalDefId, MacroKind>, | |||
registered_tools: RegisteredTools, | |||
lang_items: Vec<(LocalDefId, LangItem)>, | |||
missing_lang_items: Vec<LangItem>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit: could you move it to some other place (e.g. to the end), so these fields don't end up in the middle of macro-related stuff.
} | ||
// range literals desugar to a struct literal or `RangeInclusive::new(..)` | ||
matches!(expr.kind, ExprKind::Call(..) | ExprKind::Struct(..)) | ||
&& expr.span.is_desugaring(DesugaringKind::RangeLiteral) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it should be possible to use comparisons with lang item def ids to detect range expressions without introducing a new DesugaringKind
.
Using expansion machinery in AST lowering is not a good practice, and I'd like to try eliminating it somehow.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've wondered about this too. Do you think all of hygiene::ExpnKind::{AstPass, Desugaring, Inlined}
are bad?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tentatively yes, I just never had time to think what better alternatives are possible.
(Except for AstPass
, it's used just like it's supposed to be.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe it could work similar to hir_attrs
.
@@ -518,7 +518,7 @@ pub fn panicking() -> bool { | |||
} | |||
|
|||
/// Entry point of panics from the libcore crate (`panic_impl` lang item). | |||
#[cfg(not(test))] | |||
#[cfg(not(any(test, doctest)))] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess this is necessary because rustdoc unconditionally runs the lang item collection pass now.
We probably need to run benchmarks on this PR to check how it affects performance.
@@ -45,6 +45,5 @@ fn main() { | |||
StructAsync { callback }.await; | |||
//~^ ERROR expected `fn() -> impl Future<Output = ()> {callback}` to be a fn item that returns `Pin<Box<(dyn Future<Output = ()> + 'static)>>`, but it returns `impl Future<Output = ()>` | |||
//~| ERROR expected `fn() -> impl Future<Output = ()> {callback}` to be a fn item that returns `Pin<Box<(dyn Future<Output = ()> + 'static)>>`, but it returns `impl Future<Output = ()>` | |||
//~| ERROR expected `fn() -> impl Future<Output = ()> {callback}` to be a fn item that returns `Pin<Box<(dyn Future<Output = ()> + 'static)>>`, but it returns `impl Future<Output = ()>` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It would be better if this PR was a pure refactoring not changing any logic, including diagnostics, if possible.
This PR is large and it's hard to notice and review any such changes.
@@ -1,8 +1,11 @@ | |||
error[E0152]: found duplicate lang item `panic_impl` | |||
--> $DIR/duplicate_entry_error.rs:11:1 | |||
| | |||
LL | fn panic_impl(info: &PanicInfo) -> ! { | |||
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ | |||
LL | / fn panic_impl(info: &PanicInfo) -> ! { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is the "head span" logic implemented for HIR only?
It should be portable to AST pretty easily, IIRC.
The HIR paths for lang items are still artificial, but this still looks like an improvement because they mimic regular paths now and can be processed by the same logic. Was this idea discussed anywhere previously? Does it interfere with any other plans? |
@camsteffen any updates on this? it has bitrotted severely :P |
We currently use Maybe this PR is a net-positive change as is (merge it), and the DesugaringKind problem can be handled down the road, but I'm not so sure. Seems just as well to let this sit. If you agree, I could write up an issue to block this on. |
Yeah that would be helpful. Thanks for the update |
As I try to put the issue into words, maybe I don't really understand what is the problem with |
Closing (for now) since I haven't had time for rust for a long while 😢 |
Based on #103603
Lang items can be resolved in the AST rather than the HIR. And then any HIR structures referencing
LangItem
can be replaced with their "normal" couterpart. SpecificallyQPath::LangItem
andGenericBound::LangItemTrait
are factored out.Best reviewed commit-at-a-time.