fixes#24755, refs #24710
Instead of using the node from `indexTypesMatch` which inserts a hidden
conv node, just change the type of the node back to the old type
directly
fixes#24698
The same aim as #24224 but for tuple constructors. The difference here
is that the type of a tuple constructor is always going to be valid
unlike array constructors which can have `seq` etc types, so we can just
generate a conversion again. If the conversion fails, it is ignored
similar to #24611, this is to protect against modified typed nodes in
macros.
Also #24611 was only adapted to `semTupleFieldsConstr` and not
`semTuplePositionsConstr`, this is now fixed.
fixes#24609
A tuple may have an incompatible expected type if there is a converter
match to it. So the compiler should not error when trying to match the
individual elements in the constructor to the elements of the expected
tuple type, this will be checked when the tuple is entirely constructed
anyway.
fixes#18125
Previously a tuple type like `(T, int)` would match an expected tuple
type `(U, int)` if `T` is a subtype of `U`. This is wrong since the
codegen does not handle type conversions of individual tuple elements in
a type conversion of an entire tuple. For this reason the compiler
already does not accept `(float, int)` for a matched type `(int, int)`,
however the code that checked for which relations are unacceptable
checked for `< isSubtype` rather than `<= isSubtype`, so subtypes were
not included in the unacceptable relations.
Update: Now only considered unacceptable when inheritance is used, as in
[`paramTypesMatch`](3379d26629/compiler/sigmatch.nim (L2252-L2254)).
Ideally subtype relations that don't need conversions, like `nil`,
`seq[empty]`, `range[0..5]` etc would be their own relation
`isConcreteSubtype` (which would also allow us to differentiate with
`openArray[T]`), but this is too big of a refactor for now.
To compensate for this making things like `let x: (Parent, int) =
(Child(), 0)` not compile (they would crash codegen before anyway but
should still work in principle), type inference for tuple constructors
is updated such that they call `fitNode` on the fields and their
expected types, so a type conversion is generated for the individual
subtype element.
* round out tuple unpacking assignment, support underscores
fixes#18710
* fix test messages
* use discard instead of continue
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
---------
Co-authored-by: Andreas Rumpf <rumpf_a@web.de>
* fixes#22054; codegen for var tuples conv
* rethink fixes
* add test cases
* templates only
* fixes var tuples
* keep varness no matter what
* fixes typ.isNil
* make it work for generics
* restore isSubrange
* add a test case as requested
* tuple unpacking for vars as just sugar, allowing nesting
* set temp symbol AST
* hopeful fix some issues, add test for #19364
* always use temp for consts
* document, fix small issue
* fix manual indentation
* actually fix manual
* use helper proc
* don't resem temp tuple assignment
* Tuple unpacking now works for `for` vars
* Give error if length of tuple vars != length of tuple
* Fix error message showing wrong tuple length
* unpacking now works now for mutable items
* Update changelog
* removed from `compiler`:
* lists (deprecated 2 years ago)
* removed from `lib` (all deprecated 3 years ago):
* ssl
* matchers
* httpserver
* removed from `lib/deprecated`:
* unsigned
* actors (and three accompanying tests)
* parseurl
* moved to `lib/deprecated`:
* securehash (the reason for not directly removing - it was deprecated (only) one year ago)
