-
Notifications
You must be signed in to change notification settings - Fork 28
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
CLI Option for Disabling Support for Global Variables #541
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems to me that what you really want is an option to allow lazy imports; disabling globals seems to be an unfortunate side effect, not the goal. Thus, I think this option could be framed differently and could be called `--lazyImport" - somehow, putting things this way sounds less controversial to me 😄
I agree with the restrictions that you suggest, but I would also check for usages of init
blocks.
Finally, if you depend on this, I am ok with merging it but there is one detail that is easy to miss which is that the checks seem to be performed superficially. Thus, a program that has 3 packages like this could never succeed past initialization, but Gobra (with this flag) would not report it:
main/main.go
package main
import "pkg1"
func main() {
...
}
pkg1/f.go
package pkg1
import "pkg2"
...
pkg2/f.go
package pkg2
func init() {
panic()
}
All suggestions sound good! Enforcing lazy imports for now basically means disabling global variables but it sounds more future proof as we might need to disable additional language features in the future (or reconsider the CLI option). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM!
In the future, if you think that disallowing global variables is too restrictive, one could allow them and only skip the proof obligations concerning initialization; additionally we could emit a message saying that initialization code is currently not checked when the user passes the --lazyImport flag, similarly to the message that we emit when a user uses closures.
This might be another slightly controversial PR :P
I just had again a case where Gobra wanted me to create "fake" source files for some transitively imported packages.
I'm even on the fence with myself whether I should actually do it or use my option but in any case it might be handy to (temporarily or not) disable the support for global variables.
I reject a program if it's using global variables, init postconditions or import preconditions. Did I forget any other check?