vlang / v

Simple, fast, safe, compiled language for developing maintainable software. Compiles itself in <1s with zero library dependencies. Supports automatic C => V translation. https://vlang.io
MIT License
35.82k stars 2.17k forks source link

V initialises unused modules #8744

Open clubby789 opened 3 years ago

clubby789 commented 3 years ago

V version: V 0.2.2 82650ee

What did you do?

module main

import net.http

fn main() {
    println('hi')
}
[ ... ]
v -autofree test.v
valgrind ./test

What did you expect to see? No memory leaks

What did you see instead?

==3818== HEAP SUMMARY:
==3818==     in use at exit: 199 bytes in 7 blocks
==3818==   total heap usage: 4,608 allocs, 4,601 frees, 174,297 bytes allocated

The generated C code contains initialisation blocks for net.openssl, os, net.urllib etc. As well as initialising modules that the compiler recognises as unused, autofree fails to free these allocations.

JalonSolov commented 3 years ago

Try again with -skip-unused. WIP for now, but will be the default in the future.

clubby789 commented 3 years ago

What's the reason for it being WIP? I'd be interested in contributing if there's some kind of issue tracking the feature.

JalonSolov commented 3 years ago

The reason for it being WIP is because it isn't finished, yet. :-)

clubby789 commented 3 years ago

What I meant was what are the specific parts of the problem that are currently unsolved, because I'd be interested in helping out.

JalonSolov commented 3 years ago

I'm not working on it, so I don't know. You'll have to wait for someone who has been working on it to respond. Or, take a look at the source and see if you can tell what is/isn't being done now.

medvednikov commented 1 year ago

Actually @clubby789 I wonder if that is even an issue.

Such code wouldn't even compile in Go (unused import). V has a similar warning, and vfmt can simply remove an unused import.

During dev stage it doesn't matter if init is called from the module you're going to use anyway.

dumblob commented 1 year ago

@medvednikov wouldn't that affect e.g. some tests? Tests could be sensitive to memory leaks and such and it is not a good idea to conditionally compile different tests for production builds and non-prod builds/runs.