f1c1faf65a
Rather than document the range of possible error types, requiring clumsy client code to extract position information, we now expose a single concrete type for all errors. Position information (in standardized string form) is technically optional, but we should strive for 100%, fixing gaps as they arise. This change enables us to unify the Package and JSON structs in a follow-up. Question: should we eliminate the Config.Error hook and be silent by default? Pro: + most clients suppress it. Con: - clients that want to print errors (e.g. vet-like tools) would have to traverse the entire import graph to find them. - silence is not the most fail-safe behavior. Change-Id: Ie92b9fb7641ceda429f00928474b650d1dfadedd Reviewed-on: https://go-review.googlesource.com/130576 Reviewed-by: Michael Matloob <matloob@golang.org> |
||
|---|---|---|
| .. | ||
| ast/astutil | ||
| buildutil | ||
| callgraph | ||
| gccgoexportdata | ||
| gcexportdata | ||
| internal | ||
| loader | ||
| packages | ||
| pointer | ||
| ssa | ||
| types/typeutil | ||
| vcs | ||