You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Assigning to a sink parameter that uses an instantiated generic tuple type creates an unsafe
shallow copy, which can lead to double frees, depending on the type.
Example
typeObject=object
val: intTuple[T] = (T,)
proc`=copy`(x: varObject, y: Object) =echo"copied"proc`=destroy`(x: varObject) =if x.val !=0:
echo"destroyed: ", x.val
proctest(x: sinkTuple[Object]) =var y: Tuple[Object]
y = x # last use of `x`, so this should move, or at least create a proper copytest((Object(val: 1),))
Actual Output
destroyed: 1
destroyed: 1
Expected Output
destroyed: 1
Additional Information
removing the sink makes the issue go away (no destructor is called in that case)
Tuple not being generic also makes the issue go away
The text was updated successfully, but these errors were encountered:
## Summary
* fix a double-free issue when assigning to `sink` parameters of
instantiated generic tuple type
* fix a compiler crash when passing an empty `seq`, `array`, or `set`
construction to a generic instantiation receiver type
Fixes#1415.
## Details
Post-match fitting didn't consider generic tuple instantiations when
applying implicit conversions, meaning that the `nkHiddenSubConv` or
`nkHiddenStdConv` inserted earlier by `sigmatch` stayed.
This led to two issues:
* `nkStmtListExpr`s of empty container type didn't have their types
fixed properly, causing crashes when the empty type reached into the
MIR phase
* a conversion between `sink T` and `T` is considered an rvalue
conversion by `proto_mir`, which resulted in assignments involving
these implicit conversions effectively being *shallow* assignments
(and thus double frees)
Skipping `tyGenericInst` and `tyAlias` (for good measure) makes sure
the implicit conversion is collapsed when the destination type is a
generic instantiation, fixing both issues. A test is added for both.
Assigning to a
sink
parameter that uses an instantiated generic tuple type creates an unsafeshallow copy, which can lead to double frees, depending on the type.
Example
Actual Output
Expected Output
Additional Information
sink
makes the issue go away (no destructor is called in that case)Tuple
not being generic also makes the issue go awayThe text was updated successfully, but these errors were encountered: