Be more conservative on memory effects when args are mutable

[gbaraldi]

So this is a start, but I'm still not satisfied about this, also the same treatment should probably be passed to setfield!. Though I'm not sure if it's also ever going to be valid. setfield! requires a mutable argument, so it's never going to be m.
The only way I can see this ever being refined if the types are already known is using escape analysis + getfield/setfield. Which I couldn't find if we do.

Fixes #52531

[vchuravy]

This is consistent with my analysis.

I don't fully understand the design of inaccesiblememonly I would have expected it to be w.r.t a single statement and not w.r.t the parent function.

E.g. getfield should always be argmemonly and never inaccessiblememonly. It is consistent if an only if the argument is function local (which we don't track just now?) and it does not alias a set field operation (when in a loop).

[aviatesk]

This modification might be overly conservative. The key insight from the issue is that QuoteNode can embed global variables that users can modify. I believe the right approach is to properly taint QuoteNode's :inaccessiblememonly (which we're already doing for GlobalRef).

In the current design of the effect analysis for :inaccessiblememonly, each statement is initially allowed to have the INACCESSIBLEMEM_OR_ARGMEMONLY effect, which may then be refined in adjust_effects if the arguments are proven to not have any mutability. This approach effectively replaces escape analysis with a simpler type-level analysis in the abstract interpretation phase for efficiency. While this refinement is more conservative than escape analysis, it should still be correct.

[gbaraldi]

So the confusing thing, is that if we call a function with no args, that calls a function that is ?c and ?m we somehow refine it to c m. The thing that we're missing is that we never decay the ?c to !c, even after adjust_effects. And somehow the arguments of the caller then affect how we treat this.
The weird thing is that the inaccessiblemem_or_argmemonly isn't something that the caller should inherit from the callee, because they aren't the same arguments.

[vchuravy]

So the confusing thing, is that if we call a function with no args, that calls a function that is ?c and ?m we somehow refine it to c m. T

IIUC ?c correctly its m -> c e.g. if the calling function is proven to be inaccessiblememonly we are allowed to refine ?c to c.
It is not a statement over getfield itself, essentially we don't have dataflow analysis for the obj and so we say "as long as this function globally doesn't access argmem or global mem" we are allowed to refine.

[giordano]

Can this be closed now that #52548 has been merged?