cmd/compile: untyped types reaching backend

[mdempsky]

I created CL 94027, which validates that the SSA backend never sees untyped types. This should be safe, because the compiler frontend should eliminate all untyped types during type checking.

However, the CL doesn't currently work, suggesting the frontend is doing something (at least technically) wrong.

[mdempsky]

Fixing this might be tricky, but an easy way to help would be to find some minimal test cases that reproduce failures.

1. Apply CL 94027. (Maybe change the two f.Fatalf calls to f.Logf, so you still have a working compiler.)

2. Run "go install cmd/compile" and then "go build -a std cmd".

3. Look in the output for lines like:

    ../src/strconv/atoi.go:160:15: internal compiler error: allocating value with type untyped bool
   

4. Figure out how to reproduce that error with as little code as possible. For example, this is a pretty minimal repro case (maybe it can be further simplified):

    package p
   
    func syntaxError(... interface{}) error
   
    func ParseUint(s string) (uint64, error) {
            if len(s) == 0 {
                    return 0, syntaxError("", s)
            }
            return 0, nil
    }
   

[namusyaka]

@mdempsky I don't know if I can solve this, but since I am interested, I'll try to investigate it.

[mdempsky]

@namusyaka That would be great, thanks! Feel free to ask here if you have any questions.

[fraenkel]

The example above is caused by the generated .eq.[2]interface{} method.

[mdempsky]

@fraenkel Thanks! So just

package p
type t [2]interface{}

repros that issue.

Further steps for folks interested in helping debug/fix this:

5. Run "go tool compile -W repro.go" and look for "untyped bool". (Make sure you're sync'd past c3e8da6, or else this will be printed as just "bool".)

6. The output is a bit tricky to understand if you're not familiar with the compiler's AST representation (see cmd/compile/internal/gc/syntax.go for hints), but you should be able to spot things like:

   .   FOR l(1) colas(true) tc(1) ARRAY-[2]interface {}
   .   .   LT l(1) tc(1) untyped bool
   .   .   .   NAME-p..autotmp_4 a(true) l(1) x(0) class(PAUTO) esc(N) tc(1) assigned used int
   .   .   .   NAME-p..autotmp_5 a(true) l(1) x(0) class(PAUTO) esc(N) tc(1) assigned used int
   

   or

   .   .   IF l(1) tc(1)
   .   .   .   OROR l(1) tc(1) hascall untyped bool
   .   .   .   .   NE l(1) tc(1) untyped bool
   .   .   .   .   .   ITAB l(1) tc(1) PTR64-*uintptr
   

   These two cases reveal that during typechecking we're not forcing if or for conditions to a concrete type.

7. Find the appropriate places to add x = defaultlit(x, nil). This will probably be right after the corresponding x = typecheck(x, Erv). For example, in typecheck1's case OIF, I'd try putting it right after the n.Left = typecheck(n.Left, erv).

[fraenkel]

Fixed the OIF and OFOR. Do you want separate CLs?
The next one(s) identified are:
. . . . . ANDAND l(6) tc(1) hascall untyped bool
. . . . . . ANDAND l(6) tc(1) hascall untyped bool
. . . . . . . NE l(6) tc(1) hascall untyped bool
. . . . . . . EQ l(6) tc(1) hascall untyped bool
. . . . . . CONVNOP l(6) tc(1) hascall untyped bool
. . . . . . . LITERAL-true a(true) l(6) tc(1) untyped bool

[josharian]

Separate CLs is great. Thanks for working on this!

[gopherbot]

Change https://golang.org/cl/94475 mentions this issue: cmd/compile: Convert untyped bool for OIF and OFOR

[gopherbot]

Change https://golang.org/cl/94495 mentions this issue: cmd/compile: Convert untyped bool for comparison operators

[gopherbot]

Change https://golang.org/cl/97016 mentions this issue: cmd/compile: convert untyped bool for OEQ AND OCALLFUNC in certain case

[gopherbot]

Change https://golang.org/cl/97035 mentions this issue: cmd/compile: avoid untyped bool when comparison

[gopherbot]

Change https://golang.org/cl/97001 mentions this issue: cmd/compile: convert untyped bool during walkCases