To do this with complete accuracy requires mapping the dependent types into a context, but isOpaque is currently only used as a sanity check in assertions, and a tuple being matched to a class-constrained archetype is an unlikely enough occurrence that it's probably OK to accept this inaccuracy instead of trying to push generic contexts all the way down into isOpaque's clients.
Swift SVN r11824
with qualifiers on it, we have two distinct types:
- LValueType(T) aka @lvalue T, which is used for mutable values on the LHS of an
assignment in the typechecker.
- InOutType(T) aka @inout T, which is used for @inout arguments, and the implicit
@inout self argument of mutable methods on value types. This type is also used
at the SIL level for address types.
While I detangled a number of cases that were checking for LValueType (without checking
qualifiers) and only meant @inout or @lvalue, there is more to be done here. Notably,
getRValueType() still strips @inout, which is totally and unbearably wrong.
Swift SVN r11727
