Alan Donovan 9f640c2abb go.tools/ssa: record lvalue/rvalue distinction precisely in DebugRef. ... A DebugRef associates a source expression E with an ssa.Value V, but until now did not record whether V was the value or the address of E. So, we would guess from the "pointerness" of the Value, leading to confusion in some cases, e.g. type N *N var n N n = &n // lvalue and rvalue are both pointers Now we explicitly record 'IsAddress bool' in DebugRef, and plumb this everywhere: through (*Function).ValueForExpr and (*Program).VarValue, all the way to forming the pointer analysis query. Also: - VarValue now treats each reference to a global distinctly, just like it does for other vars. So: var g int func f() { g = 1 // VarValue(g) == Const(1:int), !isAddress print(g) // VarValue(g) == Global(g), isAddress } - DebugRefs are not emitted for references to predeclared identifiers (nil, built-in). - DebugRefs no longer prevent lifting of an Alloc var into a register; now we update or discard the debug info. - TestValueForExpr: improve coverage of ssa.EnclosingFunction by putting expectations in methods and init funcs, not just normal funcs. - oracle: fix golden file broken by recent (*types.Var).IsField change. R=gri CC=golang-dev https://golang.org/cl/16610045		2013-10-24 18:31:50 -04:00
..
objlookup.go	go.tools/ssa: record lvalue/rvalue distinction precisely in DebugRef.	2013-10-24 18:31:50 -04:00
valueforexpr.go	go.tools/ssa: record lvalue/rvalue distinction precisely in DebugRef.	2013-10-24 18:31:50 -04:00