1
0
mirror of https://github.com/golang/go synced 2024-11-18 14:14:46 -07:00
go/godoc/analysis
Alan Donovan 8e53eb937b go/ssa: support custom TestMain functions in test packages
Supporting user-defined TestMain functions requires that we generate a
"testmain" package for each testable package, rather than a single one
for the entire program.  This entails these API changes:

1. (*ssa.Program).{CreateTestMainPackage,FindTests} both now
   accept only a single package.  Existing clients that pass them
   multiple packages must call them from a loop.

2. (*ssa.Program).FindTests returns an additional result, the the
   optional TestMain *ssa.Function.  Existing clients may discard it.

Also:
- Test the new logic using the SSA interpreter
- add ssautil.MainPackages helper
- callgraph: allow multiple main packages, and analyze them all
- ssadump -run: allow multiple main/test packages, and run each in a new interpreter
- minor simplifications to some callers (e.g. guru)

Fixes golang/go#9553

Change-Id: Ia7de9bd27448fb08b8d172ba5cdbcf37a762b7a0
Reviewed-on: https://go-review.googlesource.com/25102
Reviewed-by: Robert Griesemer <gri@golang.org>
2016-10-19 17:50:59 +00:00
..
analysis.go go/ssa: support custom TestMain functions in test packages 2016-10-19 17:50:59 +00:00
callgraph.go tools: switch to standard go/types at tip 2016-01-06 22:15:26 +00:00
implements.go tools: switch to standard go/types at tip 2016-01-06 22:15:26 +00:00
json.go go.tools/godoc: server mode: add support for type and pointer analysis. 2014-03-14 18:58:22 -04:00
peers.go x/tools: s/oracle/guru/g in various comments 2016-10-13 18:54:04 +00:00
README x/tools: s/oracle/guru/g in various comments 2016-10-13 18:54:04 +00:00
typeinfo.go all: address vet issues, fix print calls 2016-03-27 20:36:34 +00:00

Type and Pointer Analysis to-do list
====================================

Alan Donovan <adonovan@google.com>


Overall design
--------------

We should re-run the type and pointer analyses periodically,
as we do with the indexer.

Version skew: how to mitigate the bad effects of stale URLs in old pages?
We could record the file's length/CRC32/mtime in the go/loader, and
refuse to decorate it with links unless they match at serving time.

Use the VFS mechanism when (a) enumerating packages and (b) loading
them.  (Requires planned changes to go/loader.)

Future work: shard this using map/reduce for larger corpora.

Testing: how does one test that a web page "looks right"?


Bugs
----

(*ssa.Program).Create requires transitively error-free packages.  We
can make this more robust by making the requirement transitively free
of "hard" errors; soft errors are fine.

Markup of compiler errors is slightly buggy because they overlap with
other selections (e.g. Idents).  Fix.


User Interface
--------------

CALLGRAPH:
- Add a search box: given a search node, expand path from each entry
  point to it.
- Cause hovering over a given node to highlight that node, and all
  nodes that are logically identical to it.
- Initially expand the callgraph trees (but not their toggle divs).

CALLEES:
- The '(' links are not very discoverable.  Highlight them?

Type info:
- In the source viewer's lower pane, use a toggle div around the
  IMPLEMENTS and METHODSETS lists, like we do in the pacakge view.
  Only expand them initially if short.
- Include IMPLEMENTS and METHOD SETS information in search index.
- URLs in IMPLEMENTS/METHOD SETS always link to source, even from the
  package docs view.  This makes sense for links to non-exported
  types, but links to exported types and funcs should probably go to
  other package docs.
- Suppress toggle divs for empty method sets.

Misc:
- The [X] button in the lower pane is subject to scrolling.
- Should the lower pane be floating?  An iframe?
  When we change document.location by clicking on a link, it will go away.
  How do we prevent that (a la Gmail's chat windows)?
- Progress/status: for each file, display its analysis status, one of:
   - not in analysis scope
   - type analysis running...
   - type analysis complete
     (+ optionally: there were type errors in this file)
   And if PTA requested:
   - type analysis complete; PTA not attempted due to type errors
   - PTA running...
   - PTA complete
- Scroll the selection into view, e.g. the vertical center, or better
  still, under the pointer (assuming we have a mouse).


More features
-------------

Display the REFERRERS relation?  (Useful but potentially large.)

Display the INSTANTIATIONS relation? i.e. given a type T, show the set of
syntactic constructs that can instantiate it:
    var x T
    x := T{...}
    x = new(T)
    x = make([]T, n)
    etc
    + all INSTANTIATIONS of all S defined as struct{t T} or [n]T
(Potentially a lot of information.)
(Add this to guru too.)


Optimisations
-------------

Each call to addLink takes a (per-file) lock.  The locking is
fine-grained so server latency isn't terrible, but overall it makes
the link computation quite slow.  Batch update might be better.

Memory usage is now about 1.5GB for GOROOT + go.tools.  It used to be 700MB.

Optimize for time and space.  The main slowdown is the network I/O
time caused by an increase in page size of about 3x: about 2x from
HTML, and 0.7--2.1x from JSON (unindented vs indented).  The JSON
contains a lot of filenames (e.g. 820 copies of 16 distinct
filenames).  20% of the HTML is L%d spans (now disabled).  The HTML
also contains lots of tooltips for long struct/interface types.
De-dup or just abbreviate?  The actual formatting is very fast.