Fix higher order blackboxes not propagating usage metadata#3148
Fix higher order blackboxes not propagating usage metadata#3148
Conversation
755916f to
c52cf26
Compare
|
Sad to say neither verilator or yosys catch this as a warning. And just text based checks really sucks because on my machine this text based check passes but I guess with different GHC/Clash combinations the exact ordering can be different. |
10982ba to
53fee98
Compare
53fee98 to
507b203
Compare
507b203 to
661931c
Compare
|
The given reproducer in the issue actually wasn't a reproducer, but with explicit clocks it does reproduce. For the verification all sequential assignments to identifiers are gathered and it's checked the identifiers are declared as |
martijnbastiaan
left a comment
There was a problem hiding this comment.
I'm not 100% sure on the fix, but the tests look like they actually test something sensible to ✔️
|
Let's wait for the grandmaster @christiaanb to see if he thinks this is the proper fix. |
91449e2 to
31104d3
Compare
| -- Pick the fSubPos-th HO instantiation (if present) and reuse its usage. | ||
| case IntMap.lookup fPos (bbFunctions bbCtx) >>= listToMaybe . drop fSubPos of | ||
| Just (_, usage, _, _, _, _) -> declareUseOnce usage resName | ||
| Nothing -> pure () |
There was a problem hiding this comment.
Is this what we want? Should we be allowed to instantiate a function argument more often that its function plurality? Shouldn't we error out if that happens? @martijnbastiaan
31104d3 to
d2b317a
Compare
Uh oh!
There was an error while loading. Please reload this page.