-
Notifications
You must be signed in to change notification settings - Fork 17.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmd/vet: time.Since should not be used in defer statement #60048
Comments
A quick search for
|
I looked into this in the public corpus and found tons of hits for time.Since called as an argument to a deferred call; all of them seemed wrong. Are there other such functions that are worth checking and commonly misused? |
This proposal has been added to the active column of the proposals project |
Based on the discussion above, this proposal seems like a likely accept. |
Change https://go.dev/cl/499875 mentions this issue: |
This is adding an analysis pass to catch defer statements where people intend to invoke a defer arguments when the defer is ran; not when it is first invoked. In order to acheive this, the current analyasis implementation first uses the inspect.Preorder tool to look for defer nodes. It then walks the defer node expression tree. This solution means that we don't catch function literals, and maybe it's slightly unoptimized because it doesn't use the Inspect fast node filtering once we find the defer nodes. Updates golang/go#60048. Change-Id: I50ec60c7fc4a5ced858f42cb8db8e9ea37a7038f
No change in consensus, so accepted. 🎉 |
This is adding an analysis pass to catch defer statements where people intend to invoke a defer arguments when the defer is ran; not when it is first invoked. In order to achieve this, the current analyasis implementation first uses the inspect.Preorder tool to look for defer nodes. It then walks the defer node expression tree. This solution means that we don't catch function literals, and maybe it's slightly unoptimized because it doesn't use the Inspect fast node filtering once we find the defer nodes. Updates golang/go#60048. Change-Id: I50ec60c7fc4a5ced858f42cb8db8e9ea37a7038f Reviewed-on: https://go-review.googlesource.com/c/tools/+/499875 TryBot-Bypass: Alan Donovan <adonovan@google.com> Reviewed-by: Alan Donovan <adonovan@google.com> Reviewed-by: Robert Findley <rfindley@google.com> Auto-Submit: Alan Donovan <adonovan@google.com> gopls-CI: kokoro <noreply+kokoro@google.com> Run-TryBot: Alan Donovan <adonovan@google.com>
Change https://go.dev/cl/502975 mentions this issue: |
This change enables the new defers analyzer in gopls. It also adds it to the vet compatibility test. A follow-up change will add it to vet itself. Also, remove stray backquote in doc comment. Updates golang/go#60048 Change-Id: I42f09bb79fcbe4e48593dd32fd066ddd39b9626f Reviewed-on: https://go-review.googlesource.com/c/tools/+/502975 Run-TryBot: Alan Donovan <adonovan@google.com> Auto-Submit: Alan Donovan <adonovan@google.com> Reviewed-by: Robert Findley <rfindley@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
Hey this is has been in gopls for a month now, @alandonovan should I open a change adding this to vet? |
Yes, that would be great. Thanks! |
Change https://go.dev/cl/527095 mentions this issue: |
Remove usage of `vet = True` in nogo definition. It's simply a shortcut attribute to appends some additional analyzers to the nogo binary. Instead, run `go tool vet help` and copy all listed analyzers in the doc to our analyzer. This list is more up-to-date than the one in current rules_go. Fix 2 vet issues found with new analyzers added: - Misuse of unbuffered os.Signal channel as argument to signal.Notify The channel should be buffered with minimal size of 1. - time.Since should not be used in defer statement See golang/go#60048 for more information
* Fix how time.Since should be used with defer as described in golang/go#60048 * Previously time.Since(start) is evaluated immediately when the defer is defined which means the latency recorded is always 0 seconds. By moving the time.Since into a function, it does not get evaluated until the function is called which properly times the processing latency.
* Fix how time.Since should be used with defer as described in golang/go#60048 * Previously time.Since(start) is evaluated immediately when the defer is defined which means the latency recorded is always 0 seconds. By moving the time.Since into a function, it does not get evaluated until the function is called which properly times the processing latency.
This commit fixes the complaining from `go vet` about the deferring of `time.Since`. This can cause wrong time evaluation of the elapsed time. This impact only the debug level, but still it should be addressed. ref: golang/go#60048
This commit fixes the complaining from `go vet` about the deferring of `time.Since`. This can cause wrong time evaluation of the elapsed time. This impact only the debug level, but still it should be addressed. ref: golang/go#60048 Signed-off-by: Maurizio Del Corno <druznek@gmail.com>
This commit fixes the complaining from `go vet` about the deferring of `time.Since`. This can cause wrong time evaluation of the elapsed time. This impact only the debug level, but still it should be addressed. To make the code a little bit more readable, I wrote a method on the `immuClient` instance with the signature `debugElapsedTime(method string, start time.Time)`. ref: golang/go#60048 Signed-off-by: Maurizio Del Corno <druznek@gmail.com>
This commit fixes the complaining from `go vet` about the deferring of `time.Since`. This can cause wrong time evaluation of the elapsed time. This impact only the debug level, but still it should be addressed. To make the code a little bit more readable, I wrote a method on the `immuClient` instance with the signature `debugElapsedTime(method string, start time.Time)`. ref: golang/go#60048 Signed-off-by: Maurizio Del Corno <druznek@gmail.com>
This commit fixes the complaining from `go vet` about the deferring of `time.Since`. This can cause wrong time evaluation of the elapsed time. This impact only the debug level, but still it should be addressed. To make the code a little bit more readable, I wrote a method on the `immuClient` instance with the signature `debugElapsedTime(method string, start time.Time)`. ref: golang/go#60048 Signed-off-by: Maurizio Del Corno <druznek@gmail.com>
Background
People unfamiliar to the intricacies of the defer statement might expect that this code will print 1s, but it prints 0s. (See on go playground).
A correct version is:
This is expected behaviour, but seems to be a somewhat common gotcha. I've made the mistake on a few occasions. I did a search with github codesearch and I found several instances where this is happening in public repositories, some examples:
Summary
I can't think of many use-cases where one calls
defer f(time.Since(t))
and intends the behaviour to work as it does. I propose that a vet check is added to disallow this case.I have implemented an analyser that does this already BTW but the guidelines indicate I should open an issue first for discussion.
The text was updated successfully, but these errors were encountered: