Skip to content

Conversation

@aviatesk
Copy link
Member

  • add missing @nospecialize annotation
  • add more type annotations to functions
  • fixed capturing uninferrable variables

@aviatesk aviatesk added the backport 1.12 Change should be backported to release-1.12 label Apr 17, 2025
(b::Core.Binding, bpart::Core.BindingPartition, world::UInt)->
Pair{WorldRange, Pair{Core.Binding, Core.BindingPartition}}(WorldRange(bpart.min_world, bpart.max_world), b=>bpart),
interp, g, wwr)
function scan_partitions(query::Function, interp::AbstractInterpreter, g::GlobalRef, wwr::WorldWithRange)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we mean for these all to be ::F {where F<:Function} ?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does ::F where F<:Function still lead to different specialization than ::Function? I'm just borrowing this annotation from what @Keno is using elsewhere.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, get_compileable_sig still implements the de-specialization heuristics.
I'd change these signatures in a separate PR.

return Pair{Any,Any}(newty, ErrorException)
end
(valid_worlds, ret) = scan_partitions((interp, _, partition)->global_assignment_binding_rt_exct(interp, partition, newty), interp, g, sv.world)
newty′ = Ref{Any}(newty)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
newty′ = Ref{Any}(newty)
newty′ = Core.Box(newty)

I think that's a bit more canonical (esp for JET and other analysis tools)?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

JET can analyze both cases.

Since the frontend inserts Core.Box, are you suggesting we should consistently use Core.Box for captured variables?

I slightly prefer Ref because .contents is a bit long, but I don't have a strong preference.

- add missing `@nospecialize` annotation
- add more type annotations to functions
- fixed capturing uninferrable variables
@aviatesk aviatesk force-pushed the avi/minor-absint-refactor branch from 86ea8e9 to 939ead0 Compare April 17, 2025 18:00
@aviatesk aviatesk merged commit 5c869cd into master Apr 18, 2025
7 checks passed
@aviatesk aviatesk deleted the avi/minor-absint-refactor branch April 18, 2025 13:58
aviatesk added a commit that referenced this pull request Apr 18, 2025
- add missing `@nospecialize` annotation
- add more type annotations to functions
- fixed capturing uninferrable variables
@aviatesk aviatesk mentioned this pull request Apr 18, 2025
51 tasks
@KristofferC KristofferC removed the backport 1.12 Change should be backported to release-1.12 label Apr 25, 2025
serenity4 pushed a commit to serenity4/julia that referenced this pull request May 1, 2025
…58154)

- add missing `@nospecialize` annotation
- add more type annotations to functions
- fixed capturing uninferrable variables
LebedevRI pushed a commit to LebedevRI/julia that referenced this pull request May 2, 2025
…58154)

- add missing `@nospecialize` annotation
- add more type annotations to functions
- fixed capturing uninferrable variables
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants