Skip to content

bpart: Also partition ->deprecated #57449

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

Merged
merged 1 commit into from
Feb 28, 2025
Merged

bpart: Also partition ->deprecated #57449

merged 1 commit into from
Feb 28, 2025

Conversation

Keno
Copy link
Member

@Keno Keno commented Feb 18, 2025

This repeats the exercise in #57405. This is required for correctness, because the ->deprecated flag also affects using resolution (since it makes the tagged binding weaker for using purposes). That said, in general our ->deprecated semantics have been somewhat underspecified with lots of XXX comments in the surrounding code. This tries to define the semantics to give a depwarn on access (read or write) when:

  1. Either the binding itself is deprecated; or
  2. The implicit imports pass through a deprecated binding.

However, we do not give depwarns on access to bindings that were explicitly imported (although we do give those warnings on the import) - the reasoning being that it's the import that needs to be adjusted not the access.

Additionally, this PR moves into the direction of making the depwarn a semantic part of the global access, by adjusting codegen and inference appropriately.

@Keno Keno force-pushed the kf/partitiondeprecated branch from 48120f3 to 9c24a65 Compare February 27, 2025 20:58
This repeats the exercise in #57405. This is required for correctness,
because the ->deprecated flag also affects `using` resolution (since
it makes the tagged binding weaker for `using` purposes). That said,
in general our `->deprecated` semantics have been somewhat underspecified
with lots of `XXX` comments in the surrounding code. This tries to define
the semantics to give a depwarn on *access* (read or write) when:

1. Either the binding itself is deprecated; or
2. The implicit imports pass through a deprecated binding.

However, we do not give depwarns on access to bindings that were explicitly
imported (although we do give those warnings on the import) - the reasoning
being that it's the import that needs to be adjusted not the access.

Additionally, this PR moves into the direction of making the depwarn a
semantic part of the global access, by adjusting codegen and inference
appropriately.
@Keno Keno force-pushed the kf/partitiondeprecated branch from 9c24a65 to de19930 Compare February 27, 2025 22:40
@Keno Keno merged commit 1a3cbb1 into master Feb 28, 2025
5 of 7 checks passed
@Keno Keno deleted the kf/partitiondeprecated branch February 28, 2025 03:33
@KristofferC
Copy link
Member

My guess is this should be backported...

@KristofferC KristofferC added the backport 1.12 Change should be backported to release-1.12 label Mar 4, 2025
KristofferC pushed a commit that referenced this pull request Mar 4, 2025
This repeats the exercise in #57405. This is required for correctness,
because the ->deprecated flag also affects `using` resolution (since it
makes the tagged binding weaker for `using` purposes). That said, in
general our `->deprecated` semantics have been somewhat underspecified
with lots of `XXX` comments in the surrounding code. This tries to
define the semantics to give a depwarn on *access* (read or write) when:

1. Either the binding itself is deprecated; or
2. The implicit imports pass through a deprecated binding.

However, we do not give depwarns on access to bindings that were
explicitly imported (although we do give those warnings on the import) -
the reasoning being that it's the import that needs to be adjusted not
the access.

Additionally, this PR moves into the direction of making the depwarn a
semantic part of the global access, by adjusting codegen and inference
appropriately.

(cherry picked from commit 1a3cbb1)
@KristofferC KristofferC removed the backport 1.12 Change should be backported to release-1.12 label Mar 24, 2025
serenity4 pushed a commit to serenity4/julia that referenced this pull request May 1, 2025
This repeats the exercise in JuliaLang#57405. This is required for correctness,
because the ->deprecated flag also affects `using` resolution (since it
makes the tagged binding weaker for `using` purposes). That said, in
general our `->deprecated` semantics have been somewhat underspecified
with lots of `XXX` comments in the surrounding code. This tries to
define the semantics to give a depwarn on *access* (read or write) when:

1. Either the binding itself is deprecated; or
2. The implicit imports pass through a deprecated binding.

However, we do not give depwarns on access to bindings that were
explicitly imported (although we do give those warnings on the import) -
the reasoning being that it's the import that needs to be adjusted not
the access.

Additionally, this PR moves into the direction of making the depwarn a
semantic part of the global access, by adjusting codegen and inference
appropriately.
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.

2 participants