I think the root cause is on the func below. It should be extended to handle invalid values for other number systems.

func (s *Scanner) digits(base int, invalid *int) (digsep int) {
	if base <= 10 {
		max := rune('0' + base)
		for isDecimal(s.ch) || s.ch == '_' {
			ds := 1
			if s.ch == '_' {
				ds = 2
			} else if s.ch >= max && *invalid < 0 {
				*invalid = s.offset // record invalid rune offset
			}
			digsep |= ds
			s.next()
		}
	} else {
		for isHex(s.ch) || s.ch == '_' {
			ds := 1
			if s.ch == '_' {
				ds = 2
			}
			digsep |= ds
			s.next()
		}
	}
	return
}

CC @griesemer via https://dev.golang.org/owners

It's a bit of a judgement call: in both cases, when we see a character (9 or a) that's not a valid octal, we can decide that 1) the number is finished and the next character belongs to the next token, or 2) the number contains an invalid digit. But we should probably handle both cases the same.

Looking at this more closely, the "inconsistent" behavior is actually deliberate: the number 01 is a valid octal number, but 018 is not because the numeric value of the character 8 is equal the number base (which is 8). So we could stop accepting digits at this point and we would get the error "unexpected 8 in argument list", etc. But 018e0 is a valid floating-point number (with value 18.0). Thus, the scanner cannot stop when it sees the 8, it must accept at least the characters 8 and 9.

Per the spec:

While breaking the input into tokens, the next token is the longest sequence of characters that form a valid token.

When the scanner sees the sequence 01A it sees two valid tokens 01 and A. When it sees the sequence 018 there's no error yet (there could be an e following). Only when it sees, say an ), do we know the token boundary and then we can provide the error about 018 being incorrect. It's a bit different when we use the 0o notation (we know it cannot be a floating-point number). But it's the same when we use the '0x` notation (we could have a hex floating-point number).

In general one may have to look ahead (or step back) arbitrarily far: there can be arbitrary many digits in 09....9 before we see an e or something else.

Basically, the spec says that the lexer only ever reads a piece of source text once, in correct code. We could be more clever in incorrect code but it gets very complicated very quickly with number literals and it's not worth the effort, given that these kinds of errors are very rare.

Thus, this is all working as intended. Closing.