More JET fixes#2256
Conversation
These pop up as part of inference in various places
Allow it to deduce from types that certain code is safe, and c is never used undefined
This helper e.g. JET to reason about the code. And humans generally appreciate such a hint, too.
We do not define copy for RingElem in general, but deepcopy is (usually) available.
After all it is a key for lookuptable, which must be an Int.
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #2256 +/- ##
==========================================
- Coverage 88.07% 88.06% -0.02%
==========================================
Files 126 126
Lines 31728 31736 +8
==========================================
+ Hits 27946 27948 +2
- Misses 3782 3788 +6 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
lgoettgens
left a comment
lgoettgens
left a comment
There was a problem hiding this comment.
Happy about most changes, but one important comment below
| return _numpart(Int(n), _numPartsTableBig) | ||
| end | ||
| end | ||
|
|
||
| function _numpart(n::T, lookuptable::Dict{Int, T}) where T<:Integer | ||
| function _numpart(n::Int, lookuptable::Dict{Int, T}) where T<:Integer |
There was a problem hiding this comment.
These two changes restrict functionality! I would be in favor of reverting them for now and have a closer look in a different PR
There was a problem hiding this comment.
I don't think any functionality is restricted: if you look into the body of the function, n is always used as a key for lookuptable, which is of type Dict{Int,T} -- so the key must be an Int.
There was a problem hiding this comment.
had another look, now seems indeed fine
lgoettgens
added
the
release notes: not needed
2 participants
With this, it is down to 62 possible errors.