Fixes in tuple handling + output format improvements #78
Conversation
analysis/dataflow/mark.go
Outdated
| type IndexKind int | ||
|
|
||
| const ( | ||
| // ReturnedTupleIndex is index on a tuple returned by a functoin |
| for outPath := range outPaths { | ||
| if inPath != "" || outPath != "" { | ||
| if !prefixed { | ||
| prefix += "@" |
There was a problem hiding this comment.
Doesn't need to be addressed in this PR but I'm wondering if we should come up with a more efficient representation for paths? Strings are relatively expensive to update because they are immutable. Maybe it would be more efficient to use [][]byte or []string instead?
There was a problem hiding this comment.
We could, the limitation is that we need to match the pointer analysis' representation. Currently there is a 1-1 mapping between the two, they are both strings and have the same "syntax". Now that we have the pointer analysis internally, we can change that representation. We could also add some parsing step to translate between representations.
analysis/dataflow/mark.go
Outdated
| // ReturnedTupleIndex is index on a tuple returned by a functoin | ||
| ReturnedTupleIndex IndexKind = iota | ||
| // NonIndex is a non-index | ||
| NonIndex |
There was a problem hiding this comment.
Shouldn't NonIndex be the default value (0)?
There was a problem hiding this comment.
I don't think I use the default value, but that's a good point, it should be.
| @@ -76,6 +87,22 @@ func (m MarkType) String() string { | |||
| } | |||
| } | |||
|
|
|||
| // MarkIndex wraps an index kind and the index value together | |||
| type MarkIndex struct { | |||
| // Kind is the kind of index (currently, either a real index or not) | |||
There was a problem hiding this comment.
Do we plan to have other kinds of indices?
There was a problem hiding this comment.
My thinking was that some point we might want to track indices resulting from next and select instructions as a special case.
This PR improves tuple handling in the dataflow analysis: