You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Go doesn't directly allow for heap vs. stack allocation, but this is critical to ensuring high performance. You can check that variables are properly stack allocated by asking Go to report what escapes to the heap with -gcflags "-m" but this is a manual process. I propose adding a magic comment that go vet will use to check whether the variable ought to be stack allocated.
The comment should have no actual effect on escape analysis. It will merely create a visible error if something is not allocated as intended.
The text was updated successfully, but these errors were encountered:
smasher164
changed the title
Feature request: Magic comment to have go vet check that variable is stack allocated
cmd/vet: magic comment to check that variable is stack allocated
Oct 9, 2019
You can write a test using AllocsPerRun in the testing package, to ensure that some function doesn't allocate more than you expect. Is that insufficient somehow?
That’s a good question. I see this mostly as a convenience feature to make it more simple.
This would also be per variable rather than per function.
andybons
changed the title
cmd/vet: magic comment to check that variable is stack allocated
proposal: cmd/vet: magic comment to check that variable is stack allocated
Oct 10, 2019
Go vet is about detecting common mistakes.
It is out of scope to start designing vet-specific annotations and/or type-checking,
and it is also out of scope to tie anything in vet to a single compiler.
Go doesn't directly allow for heap vs. stack allocation, but this is critical to ensuring high performance. You can check that variables are properly stack allocated by asking Go to report what escapes to the heap with
-gcflags "-m"
but this is a manual process. I propose adding a magic comment thatgo vet
will use to check whether the variable ought to be stack allocated.The comment should have no actual effect on escape analysis. It will merely create a visible error if something is not allocated as intended.
The text was updated successfully, but these errors were encountered: