Didn't you know? Once the core-to-core passes are complete, a binary appears on
disk by sheer magic. And magic is never wrong.
Richard
On Oct 27, 2015, at 10:28 AM, Joachim Breitner wrote:
> Am Dienstag, den 27.10.2015, 09:44 -0400 schrieb Richard Eisenberg:
>> Phew.
Am Dienstag, den 27.10.2015, 10:41 -0400 schrieb Richard Eisenberg:
> Didn't you know? Once the core-to-core passes are complete, a binary
> appears on disk by sheer magic. And magic is never wrong.
Ah, no, I didn’t. No wonder my feeble attempts to make the code
generation for switches more
Am Dienstag, den 27.10.2015, 09:44 -0400 schrieb Richard Eisenberg:
> Phew. This was an alarming email! If a core-linted program segfaults,
> there's either a bug in CoreLint or a bug in the theory behind GHC.
> If it's the latter, someone will have an interesting paper to
> write... :)
... or in
OK, thanks to people at IRC channel(especially @rwbarton) I realized
that my lint calls were not actually running, simply because I wasn't
using -dcore-lint.. I didn't know such a flag exists, and even with
the absence of the flag I'd expect a core lint would work, because I'm
explicitly calling
| So my questions are: Am I right in assuming that CoreLint accepted programs
| should not segfault?
Yes. Modulo unsafeCoerce, and FFI calls.
| What about internal invariants? Should CoreLint check
| for those? Is there any pass that checks for invariants and prints helpful
| messages in
Ömer Sinan Ağacan writes:
> I have a very simple Core plugin that generates some functions. After my
> Core-to-Core pass is done, I'm running the linter to make sure the Core
> generated by my plugin is well-formed and well-typed. However, even though
> lint
> checker
I have a very simple Core plugin that generates some functions. After my
Core-to-Core pass is done, I'm running the linter to make sure the Core
generated by my plugin is well-formed and well-typed. However, even though lint
checker passes, the code generated by my plugin is failing with a