-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
Add public function for resolving callable AST exprs to their HIR equivalents #16705
Conversation
crates/hir/src/semantics.rs
Outdated
pub fn resolve_method_call_expr( | ||
&self, | ||
method_call_expr: &ast::MethodCallExpr, | ||
) -> Option<Function> { | ||
self.imp.resolve_method_call(method_call_expr) | ||
} |
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.
This is already exposed via deref, we should re-export SemanticsImpl
from the crate root so it and the deref impl for Semantics
gets properly documented
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.
Oh, gotcha. Removed and #16707 opened for SemanticsImpl
.
crates/hir/src/source_analyzer.rs
Outdated
db: &dyn HirDatabase, | ||
call: &ast::CallExpr, | ||
) -> Option<Callable> { | ||
self.type_of_expr(db, &call.clone().into())?.0.as_callable(db) |
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.
This returns the return type as a callable, not the function itself. resolve_call
seems unnecessary as you can just do sema.type_of_expr(call_expr.expr()).as_callable()
(with Option
handling) as is. (method calls are special because there is no nested expression that corresponds to the resolved function)
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.
Hm, yeah. I saw it used that way, but as a user of the public API without intricate knowledge of ra_ap_hir
's internals the type_of_expr
is rather non-obvious and thus easy to miss (anecdotally it took me quite a bit of searching before I found the pattern). While it doesn't strictly add any functionality that wasn't available before it makes it discoverable and thus more accessible to crate API users.
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.
Hmm, I wouldn't really say that that's related to our hir api at all, as this is effectively how rust works! A call expression is a call on some receiver expression, so in my eyes it's only logical to me that you'd query the callable on the receiver. Though I suppose we could have a general expr_as_callable(expr: &ast::Expr) -> Option<Callable>
function for discoverability and parity with the method_call
one.
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.
Good point, fn resolve_expr_as_callable
it is then! Updated.
beb80ef
to
84f6663
Compare
84f6663
to
ed34978
Compare
@bors r+ |
☀️ Test successful - checks-actions |
1 similar comment
☀️ Test successful - checks-actions |
👀 Test was successful, but fast-forwarding failed: 422 Changes must be made through a pull request. |
(the PR is motivated by an outside use of the
ra_ap_hir
crate that would benefit from being able to walk ahir::Function
's AST, resolving callable exprs within to their HIR equivalents)