supports @inline/@noinline annotations within a function body
#41312
Conversation
aviatesk
force-pushed
the
avi/doinline
branch
2 times, most recently
from
9789c0e
to
c9c607c
Compare
Separated from #40754 for the sake of easier review. The primary motivation for this change is to annotate `@inline`/`@noinline` to anonymous functions created from `do` block: ```julia f() do @inline # makes this anonymous function to be inlined ... # function body end ``` We can extend the grammar so that we have special "declaration-macro" supports for `do`-block functions like: ```julia f() @inline do # makes this anonymous function to be inlined ... # function body end ``` but I'm not sure which one is better. Following [the earlier discussion](#40754 (comment)), this commit implements the easiest solution. Co-authored-by: Joseph Tan <[email protected]>
| !!! note | ||
| If the function is trivial (for example returning a constant) it might get inlined anyway. | ||
| """ | ||
| macro noinline(ex) | ||
| esc(isa(ex, Expr) ? pushmeta!(ex, :noinline) : ex) | ||
| end | ||
| macro noinline() Expr(:meta, :noinline) end |
There was a problem hiding this comment.
Does this mean we can delete Core.@_noinline_meta() also?
There was a problem hiding this comment.
Yeah, I think we can unify them. Will do that in a follow up PR though.
❌ Do not want! 😄 |
…liaLang#41312) * supports `@inline`/`@noinline` annotations within a function body Separated from JuliaLang#40754 for the sake of easier review. The primary motivation for this change is to annotate `@inline`/`@noinline` to anonymous functions created from `do` block: ```julia f() do @inline # makes this anonymous function to be inlined ... # function body end ``` We can extend the grammar so that we have special "declaration-macro" supports for `do`-block functions like: ```julia f() @inline do # makes this anonymous function to be inlined ... # function body end ``` but I'm not sure which one is better. Following [the earlier discussion](JuliaLang#40754 (comment)), this commit implements the easiest solution. Co-authored-by: Joseph Tan <[email protected]> * Update base/expr.jl * Update base/expr.jl * Update NEWS.md Co-authored-by: Joseph Tan <[email protected]>
|
I've created the shiny new "Add to Compat" label. Keep in mind that's not intended to be a requirement for the PR author before merging, and it can be done by anyone, anytime. The intent is that by tagging PRs with this label, we may have a better sense for likely trouble when we start running release-validation tests, and it may also encourage dissemination of excellent new features across the package ecosystem. While this looks eminently backportable via Compat.jl, the intent is that this can be used even when the only possible version that could be added to Compat.jl is a "stub" implementation that simply avoids an error, allowing the new construct to be used in packages even for Julia versions where it won't actually have any effect. Motivated by #42087. |
|
Sounds great, thanks. Do you think we want to tag #41328 with the label also ? |
xrefs: - <JuliaLang/julia#41312> - <JuliaLang/julia#41328> Built on top of <#752>.
xrefs: - <JuliaLang/julia#41312> - <JuliaLang/julia#41328> Built on top of <#752>.
Separated from #40754 in order to make the review/discussion more easier and clearer.
The primary motivation for this change is to annotate
@inline/@noinlineto anonymous functions created fromdoblock:We can extend the grammar so that we have special "declaration-macro"
supports for
do-block functions like:but I'm not sure which one is better.
Following the earlier discussion,
this commit implements the easiest solution.
/cc @dghosef , @tkf