Skip to content
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

bpart: Also partition ->deprecated #57449

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

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.

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.
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.

1 participant