Closed fingolfin closed 3 months ago
Attention: Patch coverage is 87.50000%
with 1 line
in your changes missing coverage. Please review.
Project coverage is 85.96%. Comparing base (
79c9770
) to head (e8811e5
).
Files | Patch % | Lines |
---|---|---|
src/flint/fmpz.jl | 83.33% | 1 Missing :warning: |
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
For the added method
is_unit(a::ZZRingElem) = data(a) == 1 || data(a) == -1
did you on purpose not add GC.@preserve a
?
For the added method
is_unit(a::ZZRingElem) = data(a) == 1 || data(a) == -1
did you on purpose not add
GC.@preserve a
?
Yes. Why should it be necessary?
Needs a rebase, ZZRingElemOrPtr exists twice
Rebased.
@thofma my question was genuine: while I don't see why the new is_zero
/ is_one
/ is_unit
methods might need GC.@preserve
. My reasoning is this: we just read the content of the struct via Julia code, into an Int -- afterwards this is just an Int
and we can do with it whatever we want, and it doesn't matter if Julia GC's the ZZRingElem
we got the value from in the meantime. So no need for GC.@preserver
.
But at the same time I fully realize that I may be missing something, and I would appreciate if you share your concerns if you still have any!
And while at it, perhaps a good time to also ping @benlorenz in case he has 5 minutes to look at this.
So once we do a = x.d
, in these three functions here whatever we do with the a
is independent from whether x
is garbage collected or not, right? Just wanted to double check.
... and also is_zero_entry for ZZMatrix and FpMatrix.
Moreover, low-level accessors for ZZRingElem now also work for Ref{ZZRingElem} in addition to Ptr{ZZRingElem} and ZZRingElem.