Fix justActive condition

[danielwe]

Closes #1935

Let me know if there's a better/more correct solution

[wsmoses]

So I understand the failure but I’m confused why this would resolve it.

@vchuravy do you have cycles to review as well

[danielwe]

As mentioned in #1935 (comment), the problem is that a struct that contains non-isbits fields and can be incompletely initialized will not be allocated inline, even if it is immutable. As such, it's an error to conclude anything about activity from allocatedinline. A type can have immutable semantics and thus contain active values even if it is not allocated inline.

A mutable type, however, is of either duplicated or const type, hence it's safe to take this early return path. (Judging by #1926 this is true even if the mutable type has differentiable const fields.)

[danielwe]

I suppose since a non-inlined value necessarily has a memory address, an alternative would be to disregard the purported immutability and let make_zero! zero out the relevant fields anyway. However, the ccall(:jl_set_nth_field, ...) solution from #1926 doesn't work on these types, so it would have to be done with raw pointer twiddling.

But this doesn't sound appealing to me for several reasons, the most important of which is that you can now get a DupState type by nesting an immutable ActiveState type inside an immutable container (provided the justActive = false case is changed to be consistent with this choice). See Tuple{Incomplete} from the test case for an example; in other words, this would require a user to annotate an Incomplete argument as Active or MixedDuplicated, but a Tuple{Incomplete} argument as Duplicated. This would be non-intuitive, hard to reason about, and probably even harder to explain to users. Better to respect that Incomplete is immutable as declared. That leaves us with the above conclusion: you can't use allocatedinline to conclude about activity state.