@ianlancetaylor What investigation does this need? Is it something I could tackle?

The "investigation" that it needs is exactly the answer to your question in the last paragraph: do people like @griesemer agree that this is a bug? @griesemer is on vacation this month and will no doubt take a look when he returns.

This does look like a bug to me; and there doesn't seem to be a test expecting these erroneous constants either. If there was any intent behind this at some point, I don't remember.

It seems ok to fix this; I'd be surprised if existing code relies on this, especially because the respective constant literals wouldn't make it through the strconv routines anyway.

The fix might be as simple as:

diff --git a/src/text/scanner/scanner.go b/src/text/scanner/scanner.go
index 4e76664dc0..893a4edbaf 100644
--- a/src/text/scanner/scanner.go
+++ b/src/text/scanner/scanner.go
@@ -384,6 +384,9 @@ func (s *Scanner) scanExponent(ch rune) rune {
                if ch == '-' || ch == '+' {
                        ch = s.next()
                }
+               if !isDecimal(ch) {
+                       s.error("illegal exponent")
+               }
                ch = s.scanMantissa(ch)
        }
        return ch

(plus test cases, etc.)

Thanks, @griesemer. I'll see about writing up a CL with tests when I get back from vacation in a week or so.

Change https://golang.org/cl/129095 mentions this issue: text/scanner: don't allow Float exponents with no mantissa

@griesemer I added the fix you suggested and also tests to match: https://go-review.googlesource.com/c/go/+/129095

One of the things that was a bit unclear to me was how much data should be consumed when an error occurs. For example, parsing 0xg gives "illegal hexadecimal number" and stops just before the g, whereas parsing 0183 gives "illegal octal number" but stops at the end after the 3 (Playground link). What we have here for the exponent error is simple and greedy (it stops after the e and the +), which I guess is fine.

@benhoyt The scanner should consume characters as long as they are possibly leading to a valid token, and stop as soon as an error is detected. (I'm not saying this is what happens consistently, but at least that's the idea.)

For 0xg, 0x clearly is a valid start, and the g is clearly invalid so we don't consume it. For 0183 we only know after looking at the next character if it is valid or not (0183. is a valid floating point number), so this seems consistent.