Enabling stack tracing changes the program semantics sometimes.
Problem to solve
I encountered a severe problem with regards to profiling.
If you fetch your dependencies and compile your code for the first time with profiling enabled, everything works fine. However, if your compilation after fetching is without profiling but enable it in later compilations, the profiling not only doesn't work but code from modules is also messed up, changing the semantics of your program!
Eq.dcl:
definition module Eq
from StdOverloaded import class ==
eq :: a a -> Bool | == a
Eq.icl:
implementation module Eq
import StdOverloaded
eq :: a a -> Bool | == a
eq a b = a == b
test.icl
module test
import StdEnv
import Eq
Start = eq '#' '#'
nitrile.yml
name: test
type: Application
version: 0.1.0
clm_options:
profiling: StackTracing
dependencies:
base: ^1.0
build:
test:
script:
- clm:
main: test
src:
- .
Put these files in a directory and run:
nitrile fetch
nitrile build
./test
The output is then: True
(as it should be)
If you comment out the clm_options
and run the following commands:
rm -r nitrile-packages
nitrile fetch
nitrile build
./test
The output is then: True
(as it should be)
However, if you now enable the clm_options
again and run the following commands:
nitrile build
./test
The output is: False
!
I think this is an issue with clm
. It does not occur in clean 3.1. It seems that the compilation directive of _system.abc
change when changing the profiling settings. This is something that does not happen in clean 3.1.
Also, I've tested this with older versions of clm
also and it exists as early as 1.0
.
Proposal
Documentation
n.a.