Closed MohamedGhardallou closed 2 years ago
It seems that we should reset the id counter for helper variables on recursive compilation.
Fixed this issue in branch issue3
.
@MohamedGhardallou: feel free to test it, before I merge it into the main branch.
Hello, Yes, the bug is fixed and the calling module generated code is no longer modified.
However I noticed also when you change one activity implemenation in the same module the calling activity code is also modified
module2.blc
import module3 "module3"
module exposes do_something
activity do_job()(k : int32)
k = 7
run module3.waitMsec(1000)
await true
end
activity do_something()(k : int32)
k = 6
run do_job()(k)
await true
end
to
module2.blc
import module3 "module3"
module exposes do_something
activity do_job()(k : int32) // activity modified : waitMsec has been removed
k = 7
await true
end
activity do_something()(k : int32)
k = 6
run do_job()(k)
await true
end
I think this change cannot be prevented. Currently the whole file is the compilation unit. If we want to prevent that the compilation of activity do_something
changes when we changed do_job
, we would need a different naming scheme for auxiliary variables, making them unique for every activity or function. Essentially that would mean, we would make functions and activities independent compilation units. Currently we have the design: 1 file = 1 compilation unit = 1 module (or program) = 1 C-file. I am not sure if more fine-grained compilation units would be an advantage.
Apart from debugging the compiler output , i don't see any real advantage i agree.
Issue solved. Merged into main branch
Hello
Describe the bug please consider the following 3 modules program:
prog.blc
module2.blc
module3.blc
Expected behaviour if we compile this program. the following files are generated :
if we change module2 code to
module2.blc
and we recompile , only these files should be changed :
but what we see is that prog.c is also changed.