POI-aware caching for operators, init= (#16492) by vasslitvinov
This takes #16261 and #16450 further by eliminating
and having the compiler behave as if it always returns false.
This turns on POI-aware caching machinery for:
- operators such as
<, assignment, etc.
- collectively, “operators” in the following discussion
CLARIFICATION. The above statement can be interpreted in two ways.
(A) When a generic function calls an operator that is visible through a POI,
we need to ensure correct reuse of cache entries for this generic function.
(B) When a generic operator calls a function that is visible through a POI,
we need to ensure correct reuse of cache entries for the operator.
This PR ensures (B).
This PR has no impact on (A). Reuse w.r.t called operators has probably
been correct since #16261, w.r.t.
init= since #16450.
deinit are not affected by these three PRs.
Visibility lookup for initializers (not for copy-initializers,
init=) follows a different code path in the compiler and is not
hooked up for POI-aware caching. Lookup for
deinit is done in a
different spot in the compiler and uses the scope of the type definition
for visibility lookup, regardless of the scope where it is invoked.
Next steps: have the effect of this PR apply to
This PR adds tests to illustrate these behaviors.
It has no impact on existing tests.
Compilation time impact is within a couple of percent, if at all.
Signed-off-by: Vassily Litvinov firstname.lastname@example.org