Sébastien Doeraene

> So then to me, the major challenge is that the current linker interface assumes that IR file implementations are valid independently from the linker being used. (This is not...

Right. That's in theory possible, indeed. I don't think it's a valid use case, though. In my mind the abstract types in `IRFileImpl` are abstract proxies for `ir.EntryPointsInfo` and `ir.Trees.ClassDef`...

This is probably not worth keeping open after 2 years of inactivity. 😅

## Possible alternative While perusing through all those UB exceptions, I realized there is also [`NegativeArraySizeException`](https://docs.oracle.com/javase/8/docs/api/java/lang/NegativeArraySizeException.html) which the linker considers UB. Perhaps instead of adding two configs (for `arrayStores` and...

I have been asking myself similar questions. I don't have a more principled answer. In principle, all users may ever want is all-checked or all-unchecked, especially if they don't want...

I don't have any data. Intuitively, `NegativeArraySizeException` alone should be much faster than either of the other two, let alone any combination. It is only one comparison at creation time....

Probably, yes. At least if it's the criteria we want to uphold, as opposed to the criteria of not creating interfering conditions within the linker. We can take more time...

Indeed, I think I kind of arrived at the same conclusion at some point. So we should indeed decide what we ultimately want, and commit to it. I'll rebase this...

The diff between #4715 and this PR can be seen here: https://gist.github.com/sjrd/1a4e4f9c6baaf7f2ec8bd2693ff6b2ba There is definitely more code in this PR, but it's not outrageous. I'm swinging back into favoring this...

Thanks. I think I addressed all your comments.