test convertible var + range conv logic
#24036
Conversation
|
Yeah basically all the failures are from the Also the same failure from #23176 by normalize is encountered again by I can easily split the For the |
|
Sure make it opt-in for the next version, then opt-out for the version after that. |
…24037) refs #24032, split from #24036 Conversion from variables of range types or base types of range types to the other are now considered mutable for `var` params, similar to how distinct types are mutable when converted to their base type or vice versa. There are 2 main differences: 1. Conversions from base types to range types need to emit `nkChckRange`, which is not generated for things like tuple/object fields. 2. Range types can still correspond to different types in the backend when nested in other types, such as `set[range[3..5]]` vs `set[range[0..5]]`. Since the convertibility check for `var` params and a check whether to emit a no-op for `nkConv` (and now also `nkChckRange`) so that the output is still addressable both use `sameType`, we accomplish this by adding a new flag to `sameType` that ignores range types, but only when they're not nested in other types. The implementation for this might be flawed, I didn't include children of some metatypes as "nested in other types", but stuff like `tyGenericInst` params are respected.
closes #24032
The
varmatch change is likely to break code but so is the potentially buggy new behavior forrangetypes being considered the same for conversions/the backendThe
varchange straight up breaks+=,*=etc for range types, making them work again individually seems counterproductive and is hard because we can't just match on anyrangetype, the base type needs to be constrained too, which there is no way to express in the core language afaikerrmsgs/t22097needs error message change