Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

cmd/compile: bad error message for stray single quote #32133

Closed
rsc opened this issue May 19, 2019 · 2 comments
Closed

cmd/compile: bad error message for stray single quote #32133

rsc opened this issue May 19, 2019 · 2 comments
Labels
FrozenDueToAge
Milestone
Go1.14

Comments

@rsc
Copy link
Contributor

rsc commented May 19, 2019 

$ cat /tmp/x.go
package p

func f() {
'
}
$ go tool compile /tmp/x.go
/tmp/x.go:4:1: '\u0000' evaluated but not used
/tmp/x.go:4:2: newline in character literal
$

The \u0000 message threw me for a little while. The second message would suffice on its own.

/cc @griesemer
@rsc rsc added this to the Go1.14 milestone May 19, 2019
@griesemer griesemer self-assigned this May 19, 2019
@gopherbot
Copy link
Contributor

Change https://golang.org/cl/192278 mentions this issue: cmd/compile/internal/syntax: add new BasicLit.Bad field indicating a lexical error

@gopherbot
Copy link
Contributor

Change https://golang.org/cl/192437 mentions this issue: cmd/compile: avoid follow-on errors for literals with syntax errors

gopherbot pushed a commit that referenced this issue Aug 29, 2019
@griesemer
cmd/compile/internal/syntax: add BasicLit.Bad field for lexical errors
117400e 
The new (internal) field scanner.bad indicates whether a syntax error
occurred while scanning a literal; the corresponding scanner.lit
string may be syntactically incorrect in that case. Store the value
of scanner.bad together with the scanner.lit in BasicLit.

Clean up error handling so that all syntactic errors use one of the
scanner's error reporting methods which also set scanner.bad. Make
use of the new field in a few places where we used to track a prior
error separately.

Preliminary step towards fixing #32133 in a comprehensive manner.

Change-Id: I4d79ad6e3b50632dd5fb3fc32ca3df0598ee77b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/192278
Reviewed-by: Matthew Dempsky <[email protected]>
tomocy pushed a commit to tomocy/go that referenced this issue Sep 1, 2019
@griesemer @tomocy
cmd/compile/internal/syntax: add BasicLit.Bad field for lexical errors
45f218f 
The new (internal) field scanner.bad indicates whether a syntax error
occurred while scanning a literal; the corresponding scanner.lit
string may be syntactically incorrect in that case. Store the value
of scanner.bad together with the scanner.lit in BasicLit.

Clean up error handling so that all syntactic errors use one of the
scanner's error reporting methods which also set scanner.bad. Make
use of the new field in a few places where we used to track a prior
error separately.

Preliminary step towards fixing golang#32133 in a comprehensive manner.

Change-Id: I4d79ad6e3b50632dd5fb3fc32ca3df0598ee77b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/192278
Reviewed-by: Matthew Dempsky <[email protected]>
tomocy pushed a commit to tomocy/go that referenced this issue Sep 1, 2019
@griesemer @tomocy
cmd/compile: avoid follow-on errors for literals with syntax errors
0b4ea9b 
- only convert literal strings if there were no syntax errors
  (some of the conversion routines exit if there is an error)
- mark nodes for literals with syntax errors to avoid follow-on
  errors
- don't attempt to import packages whose path had syntax errors

Fixes golang#32133.

Change-Id: I1803ad48c65abfecf6f48ddff1e27eded5e282c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/192437
Reviewed-by: Matthew Dempsky <[email protected]>
t4n6a1ka pushed a commit to t4n6a1ka/go that referenced this issue Sep 5, 2019
@griesemer @t4n6a1ka
cmd/compile/internal/syntax: add BasicLit.Bad field for lexical errors
a5280f0 
The new (internal) field scanner.bad indicates whether a syntax error
occurred while scanning a literal; the corresponding scanner.lit
string may be syntactically incorrect in that case. Store the value
of scanner.bad together with the scanner.lit in BasicLit.

Clean up error handling so that all syntactic errors use one of the
scanner's error reporting methods which also set scanner.bad. Make
use of the new field in a few places where we used to track a prior
error separately.

Preliminary step towards fixing golang#32133 in a comprehensive manner.

Change-Id: I4d79ad6e3b50632dd5fb3fc32ca3df0598ee77b4
Reviewed-on: https://go-review.googlesource.com/c/go/+/192278
Reviewed-by: Matthew Dempsky <[email protected]>
t4n6a1ka pushed a commit to t4n6a1ka/go that referenced this issue Sep 5, 2019
@griesemer @t4n6a1ka
cmd/compile: avoid follow-on errors for literals with syntax errors
06a2a2f 
- only convert literal strings if there were no syntax errors
  (some of the conversion routines exit if there is an error)
- mark nodes for literals with syntax errors to avoid follow-on
  errors
- don't attempt to import packages whose path had syntax errors

Fixes golang#32133.

Change-Id: I1803ad48c65abfecf6f48ddff1e27eded5e282c5
Reviewed-on: https://go-review.googlesource.com/c/go/+/192437
Reviewed-by: Matthew Dempsky <[email protected]>
@golang golang locked and limited conversation to collaborators Aug 28, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
Go1.14
Development

No branches or pull requests
3 participants
@rsc @griesemer @gopherbot