1
0
mirror of https://github.com/golang/go synced 2024-11-24 22:37:56 -07:00
Commit Graph

4 Commits

Author SHA1 Message Date
Matthew Dempsky
70544c91ff cmd/compile/internal/syntax: match old parser errors and line numbers
This makes a bunch of changes to package syntax to tweak line numbers
for AST nodes. For example, short variable declaration statements are
now associated with the location of the ":=" token, and function calls
are associated with the location of the final ")" token. These help
satisfy many unit tests that assume the old parser's behavior.

Because many of these changes are questionable, they're guarded behind
a new "gcCompat" const to make them easy to identify and revisit in
the future.

A handful of remaining tests are too difficult to make behave
identically. These have been updated to execute with -newparser=0 and
comments explaining why they need to be fixed.

all.bash now passes with both the old and new parsers.

Change-Id: Iab834b71ca8698d39269f261eb5c92a0d55a3bf4
Reviewed-on: https://go-review.googlesource.com/27199
Run-TryBot: Matthew Dempsky <mdempsky@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Robert Griesemer <gri@golang.org>
2016-08-19 01:10:21 +00:00
Robert Griesemer
539aa05a64 cmd/compile: towards simpler and faster lexing: always use getr
Always reading runes (rather than bytes) has negligible overhead
(a simple if at the moment - it can be eliminated eventually) but
simplifies the lexer logic and opens up the door for speedups.
In the process remove many int conversions that are now not needed
anymore.

Also, because identifiers are now more easily recognized, remove
talph label and move identifier lexing "in place".

Also, instead of accepting all chars < 0x80 and then check for
"frogs", only permit valid characters in the first place. Removes
an extra call for common simple tokens and leads to simpler logic.

`time go build -a net/http` (best of 5 runs) seems 1% faster.
Assuming this is in the noise, there is no noticeable performance
degradation with this change.

Change-Id: I3454c9bf8b91808188cf7a5f559341749da9a1eb
Reviewed-on: https://go-review.googlesource.com/19847
Reviewed-by: Matthew Dempsky <mdempsky@google.com>
Run-TryBot: Robert Griesemer <gri@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
2016-02-24 04:36:25 +00:00
Matthew Dempsky
7d3a40978a cmd/compile: refactor export data parsing
Merge push_parser and pop_parser into a single parse_import function
and inline unimportfile. Shake out function boundaries a little bit so
that the symmetry is readily visible.

Move the import_package call into parse_import (and inline
import_there into import_package).  This means importfile no longer
needs to provide fake import data to be needlessly lexed/parsed every
time it's called.

Also, instead of indicating import success/failure by whether the next
token is "package", import_spec can just check whether importpkg is
non-nil.

Tangentially, this somehow alters the diagnostics produced for
test/fixedbugs/issue11610.go.  However, the new diagnostics are more
consistent with those produced when the empty import statement is
absent, which seems more desirable than maintaining the previous
errors.

Change-Id: I5cd1c22aa14da8a743ef569ff084711d137279d5
Reviewed-on: https://go-review.googlesource.com/19650
Reviewed-by: Robert Griesemer <gri@golang.org>
2016-02-20 04:31:42 +00:00
Didier Spezia
70da2d0a2a cmd/compile/internal/gc: fix internal compiler error on invalid declaration
Following an empty import, a declaration involving a ? symbol
generates an internal compiler error when the name of the
symbol (in newname function).

package a
import""
var?

go.go:2: import path is empty
go.go:3: internal compiler error: newname nil

Make sure dclname is not called when the symbol is nil.
The error message is now:

go.go:2: import path is empty
go.go:3: invalid declaration
go.go:4: syntax error: unexpected EOF

This CL was initially meant to be applied to the old parser,
and has been updated to apply to the new parser.

Fixes #11610

Change-Id: I75e07622fb3af1d104e3a38c89d9e128e3b94522
Reviewed-on: https://go-review.googlesource.com/15268
Reviewed-by: Russ Cox <rsc@golang.org>
2015-12-07 20:21:21 +00:00