1
0
mirror of https://github.com/golang/go synced 2024-11-19 09:04:41 -07:00
go/ssa/visit.go

65 lines
1.6 KiB
Go
Raw Normal View History

// Copyright 2013 The Go Authors. All rights reserved.
// Use of this source code is governed by a BSD-style
// license that can be found in the LICENSE file.
package ssa
// This file defines utilities for visiting the SSA representation of
// a Program.
//
go.tools/ssa: fix computation of set of types requiring method sets. Motivation: Previously, we assumed that the set of types for which a complete method set (containing all synthesized wrapper functions) is required at runtime was the set of types used as operands to some *ssa.MakeInterface instruction. In fact, this is an underapproximation because types can be derived from other ones via reflection, and some of these may need methods. The reflect.Type API allows *T to be derived from T, and these may have different method sets. Reflection also allows almost any subcomponent of a type to be accessed (with one exception: given T, defined 'type T struct{S}', you can reach S but not struct{S}). As a result, the pointer analysis was unable to generate all necessary constraints before running the solver, causing a crash when reflection derives types whose methods are unavailable. (A similar problem would afflict an ahead-of-time compiler based on ssa. The ssa/interp interpreter was immune only because it does not require all wrapper methods to be created before execution begins.) Description: This change causes the SSA builder to record, for each package, the set of all types with non-empty method sets that are referenced within that package. This set is accessed via Packages.TypesWithMethodSets(). Program.TypesWithMethodSets() returns its union across all packages. The set of references that matter are: - types of operands to some MakeInterface instruction (as before) - types of all exported package members - all subcomponents of the above, recursively. This is a conservative approximation to the set of types whose methods may be called dynamically. We define the owning package of a type as follows: - the owner of a named type is the package in which it is defined; - the owner of a pointer-to-named type is the owner of that named type; - the owner of all other types is nil. A package must include the method sets for all types that it owns, and all subcomponents of that type that are not owned by another package, recursively. Types with an owner appear in exactly one package; types with no owner (such as struct{T}) may appear within multiple packages. (A typical Go compiler would emit multiple copies of these methods as weak symbols; a typical linker would eliminate duplicates.) Also: - go/types/typemap: implement hash function for *Tuple. - pointer: generate nodes/constraints for all of ssa.Program.TypesWithMethodSets(). Add rtti.go regression test. - Add API test of Package.TypesWithMethodSets(). - Set Function.Pkg to nil (again) for wrapper functions, since these may be shared by many packages. - Remove a redundant logging statement. - Document that ssa CREATE phase is in fact sequential. Fixes golang/go#6605 R=gri CC=golang-dev https://golang.org/cl/14920056
2013-10-23 15:07:52 -06:00
// TODO(adonovan): test coverage.
go.tools/ssa: fix computation of set of types requiring method sets. Motivation: Previously, we assumed that the set of types for which a complete method set (containing all synthesized wrapper functions) is required at runtime was the set of types used as operands to some *ssa.MakeInterface instruction. In fact, this is an underapproximation because types can be derived from other ones via reflection, and some of these may need methods. The reflect.Type API allows *T to be derived from T, and these may have different method sets. Reflection also allows almost any subcomponent of a type to be accessed (with one exception: given T, defined 'type T struct{S}', you can reach S but not struct{S}). As a result, the pointer analysis was unable to generate all necessary constraints before running the solver, causing a crash when reflection derives types whose methods are unavailable. (A similar problem would afflict an ahead-of-time compiler based on ssa. The ssa/interp interpreter was immune only because it does not require all wrapper methods to be created before execution begins.) Description: This change causes the SSA builder to record, for each package, the set of all types with non-empty method sets that are referenced within that package. This set is accessed via Packages.TypesWithMethodSets(). Program.TypesWithMethodSets() returns its union across all packages. The set of references that matter are: - types of operands to some MakeInterface instruction (as before) - types of all exported package members - all subcomponents of the above, recursively. This is a conservative approximation to the set of types whose methods may be called dynamically. We define the owning package of a type as follows: - the owner of a named type is the package in which it is defined; - the owner of a pointer-to-named type is the owner of that named type; - the owner of all other types is nil. A package must include the method sets for all types that it owns, and all subcomponents of that type that are not owned by another package, recursively. Types with an owner appear in exactly one package; types with no owner (such as struct{T}) may appear within multiple packages. (A typical Go compiler would emit multiple copies of these methods as weak symbols; a typical linker would eliminate duplicates.) Also: - go/types/typemap: implement hash function for *Tuple. - pointer: generate nodes/constraints for all of ssa.Program.TypesWithMethodSets(). Add rtti.go regression test. - Add API test of Package.TypesWithMethodSets(). - Set Function.Pkg to nil (again) for wrapper functions, since these may be shared by many packages. - Remove a redundant logging statement. - Document that ssa CREATE phase is in fact sequential. Fixes golang/go#6605 R=gri CC=golang-dev https://golang.org/cl/14920056
2013-10-23 15:07:52 -06:00
// AllFunctions finds and returns the set of functions potentially
// needed by program prog, as determined by a simple linker-style
// reachability algorithm starting from the members and method-sets of
// each package. The result may include anonymous functions and
// synthetic wrappers.
//
// Precondition: all packages are built.
//
func AllFunctions(prog *Program) map[*Function]bool {
visit := visitor{
prog: prog,
seen: make(map[*Function]bool),
}
visit.program()
return visit.seen
}
type visitor struct {
prog *Program
seen map[*Function]bool
}
func (visit *visitor) program() {
go.tools/importer: generalize command-line syntax. Motivation: pointer analysis tools (like the oracle) want the user to specify a set of initial packages, like 'go test'. This change enables the user to specify a set of packages on the command line using importer.LoadInitialPackages(args). Each argument is interpreted as either: - a comma-separated list of *.go source files together comprising one non-importable ad-hoc package. e.g. "src/pkg/net/http/triv.go" gives us [main]. - an import path, denoting both the imported package and its non-importable external test package, if any. e.g. "fmt" gives us [fmt, fmt_test]. Current type-checker limitations mean that only the first import path may contribute tests: multiple packages augmented by *_test.go files could create import cycles, which 'go test' avoids by building a separate executable for each one. That approach is less attractive for static analysis. Details: (many files touched, but importer.go is the crux) importer: - PackageInfo.Importable boolean indicates whether package is importable. - un-expose Importer.Packages; expose AllPackages() instead. - CreatePackageFromArgs has become LoadInitialPackages. - imports() moved to util.go, renamed importsOf(). - InitialPackagesUsage usage message exported to clients. - the package name for ad-hoc packages now comes from the 'package' decl, not "main". ssa.Program: - added CreatePackages() method - PackagesByPath un-exposed, renamed 'imported'. - expose AllPackages and ImportedPackage accessors. oracle: - describe: explain and workaround a go/types bug. Misc: - Removed various unnecessary error.Error() calls in Printf args. R=crawshaw CC=golang-dev https://golang.org/cl/13579043
2013-09-06 16:13:57 -06:00
for _, pkg := range visit.prog.AllPackages() {
for _, mem := range pkg.Members {
go.tools/ssa: fix computation of set of types requiring method sets. Motivation: Previously, we assumed that the set of types for which a complete method set (containing all synthesized wrapper functions) is required at runtime was the set of types used as operands to some *ssa.MakeInterface instruction. In fact, this is an underapproximation because types can be derived from other ones via reflection, and some of these may need methods. The reflect.Type API allows *T to be derived from T, and these may have different method sets. Reflection also allows almost any subcomponent of a type to be accessed (with one exception: given T, defined 'type T struct{S}', you can reach S but not struct{S}). As a result, the pointer analysis was unable to generate all necessary constraints before running the solver, causing a crash when reflection derives types whose methods are unavailable. (A similar problem would afflict an ahead-of-time compiler based on ssa. The ssa/interp interpreter was immune only because it does not require all wrapper methods to be created before execution begins.) Description: This change causes the SSA builder to record, for each package, the set of all types with non-empty method sets that are referenced within that package. This set is accessed via Packages.TypesWithMethodSets(). Program.TypesWithMethodSets() returns its union across all packages. The set of references that matter are: - types of operands to some MakeInterface instruction (as before) - types of all exported package members - all subcomponents of the above, recursively. This is a conservative approximation to the set of types whose methods may be called dynamically. We define the owning package of a type as follows: - the owner of a named type is the package in which it is defined; - the owner of a pointer-to-named type is the owner of that named type; - the owner of all other types is nil. A package must include the method sets for all types that it owns, and all subcomponents of that type that are not owned by another package, recursively. Types with an owner appear in exactly one package; types with no owner (such as struct{T}) may appear within multiple packages. (A typical Go compiler would emit multiple copies of these methods as weak symbols; a typical linker would eliminate duplicates.) Also: - go/types/typemap: implement hash function for *Tuple. - pointer: generate nodes/constraints for all of ssa.Program.TypesWithMethodSets(). Add rtti.go regression test. - Add API test of Package.TypesWithMethodSets(). - Set Function.Pkg to nil (again) for wrapper functions, since these may be shared by many packages. - Remove a redundant logging statement. - Document that ssa CREATE phase is in fact sequential. Fixes golang/go#6605 R=gri CC=golang-dev https://golang.org/cl/14920056
2013-10-23 15:07:52 -06:00
if fn, ok := mem.(*Function); ok {
visit.function(fn)
}
}
}
go.tools/ssa: fix computation of set of types requiring method sets. Motivation: Previously, we assumed that the set of types for which a complete method set (containing all synthesized wrapper functions) is required at runtime was the set of types used as operands to some *ssa.MakeInterface instruction. In fact, this is an underapproximation because types can be derived from other ones via reflection, and some of these may need methods. The reflect.Type API allows *T to be derived from T, and these may have different method sets. Reflection also allows almost any subcomponent of a type to be accessed (with one exception: given T, defined 'type T struct{S}', you can reach S but not struct{S}). As a result, the pointer analysis was unable to generate all necessary constraints before running the solver, causing a crash when reflection derives types whose methods are unavailable. (A similar problem would afflict an ahead-of-time compiler based on ssa. The ssa/interp interpreter was immune only because it does not require all wrapper methods to be created before execution begins.) Description: This change causes the SSA builder to record, for each package, the set of all types with non-empty method sets that are referenced within that package. This set is accessed via Packages.TypesWithMethodSets(). Program.TypesWithMethodSets() returns its union across all packages. The set of references that matter are: - types of operands to some MakeInterface instruction (as before) - types of all exported package members - all subcomponents of the above, recursively. This is a conservative approximation to the set of types whose methods may be called dynamically. We define the owning package of a type as follows: - the owner of a named type is the package in which it is defined; - the owner of a pointer-to-named type is the owner of that named type; - the owner of all other types is nil. A package must include the method sets for all types that it owns, and all subcomponents of that type that are not owned by another package, recursively. Types with an owner appear in exactly one package; types with no owner (such as struct{T}) may appear within multiple packages. (A typical Go compiler would emit multiple copies of these methods as weak symbols; a typical linker would eliminate duplicates.) Also: - go/types/typemap: implement hash function for *Tuple. - pointer: generate nodes/constraints for all of ssa.Program.TypesWithMethodSets(). Add rtti.go regression test. - Add API test of Package.TypesWithMethodSets(). - Set Function.Pkg to nil (again) for wrapper functions, since these may be shared by many packages. - Remove a redundant logging statement. - Document that ssa CREATE phase is in fact sequential. Fixes golang/go#6605 R=gri CC=golang-dev https://golang.org/cl/14920056
2013-10-23 15:07:52 -06:00
for _, T := range visit.prog.TypesWithMethodSets() {
mset := T.MethodSet()
for i, n := 0, mset.Len(); i < n; i++ {
visit.function(visit.prog.Method(mset.At(i)))
}
}
}
func (visit *visitor) function(fn *Function) {
if !visit.seen[fn] {
visit.seen[fn] = true
for _, b := range fn.Blocks {
for _, instr := range b.Instrs {
var buf [10]*Value // avoid alloc in common case
for _, op := range instr.Operands(buf[:0]) {
if fn, ok := (*op).(*Function); ok {
visit.function(fn)
}
}
}
}
}
}