Data flow analysis #1
Open
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Signed-off-by: Tim Henderson <[email protected]>
Signed-off-by: Tim Henderson <[email protected]>
Signed-off-by: Tim Henderson <[email protected]>
Signed-off-by: Tim Henderson <[email protected]>
Not yet sure how to handle this correctly. However, in 1.12 modules start being on by default. However, this is really "detected" by whether or not the directory in which `go` is run has a `go.mod/sum` file in it (AFAICT). This makes things "weird" with dynagrok as what dynagrok tries to do is the following: 1. Create an isolated and patched version of the Go toolchain. 2. Run that toolchain on an isolated and instrumented version of your program and all of its dependencies. 3. It does that by making a new GOPATH which contain all of your program and all of its dependencies arranged in a "traditional" GOPATH layout removing any and all "vendors". It accomplishes 3 by actually loading up your program using a library implementation of `go build` futzing with the ASTs and then writing those ASTs using the `go fmt` infrastructure into the new GOPATH. If and when Go stops supporting doing things correctly with the traditional format I may have to implement (yuck) a way to invoke `go tool compile` directly. Now I have in the distant past before the `go` command was a thing done that. I do not want to go back to that past. What does this commit actually do? It ensures when you run something that is influenced by `go.mod/sum` in your current directory you are in a directory dynagrok controls. This seemed like a more robust way to ensure that this doesn't start failing as they will eventually remove the environment variable that turns off modules. Finally, I am unsure and unwilling (at the moment) to confirm what would happen if you try and instrument a program that is setup in the GOPATH free manner using go mod. Probably dynagrok failure. Downside of all of this. Dynagrok itself will probably not be able to use `go mod` anytime soon until I understand: 1. How to correctly deal with `go mod` in dynagrok 2. Future plans for GOPATH and `go mod` in terms of build loading fin
This allows us to apply statement sensitive fault localization algorithms to the mutations created by dynagrok.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.