A list of Go 1.0.3 known compiler issues

[Rémy Oudompheng]

Hello,

I have taken some time to run the Go 1.1 compiler test suite with Go
1.0.3 and list the various issues that are present in Go 1.0.3.
Where I use Go 1.0 for production a few of the most serious issues are
patched locally. Most of these issues will be fixed in Go 1.1 and I
think the possibility of a

Incorrect code generation:
* bad hash/equal for blank fields or padding (issue 4585)
* escape analysis bug with &x.y[0] and &x.y.z (revision 0ece4ff29314)
* miscompilation of integer truncation (issue 3918, 3910).
* miscompiles expressions with "nil" (issue 3670).
* bug in initialization order (issue 3824)
* evaluates "_" in "for i, _ := range p" (issue 4173)
* corrupted cross-package inlining of complex constants (issue 4159)
* return values not saved early enough before a panic (issue 4066)
* incorrect evaluation order in select (issue 4313)
* incorrect evaluation order of map indexing (issue 4620)
* miscompilation of &^ (issue 4752)
* escape analysis bug (issue 4964)
* miscompilation of struct/array equality (issue 5162)

Internal compiler errors:
* runs "out of fixed registers" easily (issues 3835, 3907, 4156, 4201, 4207)
* hidden compiler segfault (revision 035960d0711f)
* ICE on expression containing "nil" (issue 4614)
* corrupted cross-package inlining of composite literals (issue 4230)
* broken cross-package inlining with embedded builtins (issue 3552)
* broken parsing of export data (revision 6c39cb75b6ee)
* parser stack overflow in long else-if chain (issue 2615)
* internal error when inlining T.Method(f()) (issue 4167)
* linker thinks some functions don't split stack and emits error (issue 4316)
* spurious badwidth ICE (issue 4495)
* spurious symbol redefinition error (issue 4590)
* broken inlining of gotos (issue 4748)
* ICE when importing a package with recursive type involving a map (issue 5125)

Error message cosmetics:
* nicer error message for constant definition loop (issue 3757)
* nicer error for variable used instead of type (issue 3783)
* line number issues (issue 3925)
* clean errors for index overflow (issue 4232, 4251)
* duplicate [...] error (issue 4452)
* nicer error for unused append result (issue 4463)
* nicer error for import/identifier name collision (issue 4510)
* nicer error for identifiers named init (issue 4517)
* nicer error on misused variable shadowing a type name (issue 4610)
* nicer error for "defer T(x)" where T is a type (issue 4654)
* wrong line number for switch panic (issue 4562)

Mismatch with Go 1 language spec:
* undetected initialization loop (issue 3890)
* shift bugs (issues 4545, 4882, 4936, 4937)
* embedded builtin types are wrongly exported (issue 4124)
* accepts pkg.Name as field name (issue 4067)
* accepts typed nils or len(non-constant) in constant declarations
(4097, 4673, 4680)
* accepts methods with **T receiver (issue 4458)
* accepts method definitions on external types (issue 5089)

Mismatch with Go 1.1 language spec.
* rejects BOM
* accepts complex(T1, T2) with mismatched types
* result of comparison is bool instead of untyped boolean
* does not understand method values (x.Method)
* accepts arguments with same name in function declaration (issue 4469)
* rejects floating-point constants (with integral values) as indexes
(issue 4813)
* enforces return/panic at end of function
* interprets surrogates in string(surrogate rune) differently
* accepts duplicate cases in switch
* delete on nil map panics
* accepts init functions without body (issue 3705)
* rules for constant arguments to make() (issue 4085)
* rejects final comma in conversion syntax (issue 4162)
* accepts division by constant zero (issue 4264)
* accepts invalid whitespace characters (issue 4405)
* accepts parenthesized x.(type) (issue 4470)

Runtime crash (not really a compiler issue):
* growing a slice of zero-width elements triggers division by zero (issue 4197)

No available fix for Go 1.1:
* undetected initialization loop (issue 4847)

The list is probably not exhaustive.

Rémy.

[Rémy Oudompheng]

Rémy Oudompheng <remyoud...@gmail.com> wrote:
> Where I use Go 1.0 for production a few of the most serious issues are
> patched locally. Most of these issues will be fixed in Go 1.1 and I
> think the possibility of a

This sentence got truncated: I wanted to say "the possibility of a Go
1.0.4 has already been ruled out".

Rémy.

[Dave Cheney]

Thanks Rémy, this is a very useful resource.

> --
> You received this message because you are subscribed to the Google Groups "golang-nuts" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Sébastien Paolacci]

Hi Remy,

Thanks for that valuable (and large) piece of information.

Actually, it really makes me think about the current mono-branch dev/repo model.

A few people and corporations indeed have the resources for running their own runtime. Even though I know a few of them, I would bet it's not the norm and that, at best, some profitable work might just be lost around there.

On the other-side, having both stable and dev branches might not really ease the global workflow, even more when backports and merge sessions are to show up.

An alternative solution, that doesn't come free of side-effects though, would be to have an `unofficial' community-driven backport branch that would aim at preparing, stress-testing and possibly shortening dot releases. As such, we could for example open-source our own patched runtime (nothing to hide here) to however is interested in. The burden   would however be to strip/discard all the perf patches and only stick to bugfix ones..

I however quite wonder whether it would ultimately help or hurt the main development effort.

Cheers,

Sebastien

Rémy.