For consistency with conversions that look like function calls,
conversions that don't look like function calls now allow an
optional trailing comma.
That is, int(x,) has always been syntactically valid.
Now []int(x,) is valid too.
Fixes#4162.
R=ken2
CC=golang-dev
https://golang.org/cl/7288045
Expressions involving nil, even if they can be evaluated
at compile time, do not count as Go constants and cannot
be used in const initializers.
Fixes#4673.
Fixes#4680.
R=ken2
CC=golang-dev
https://golang.org/cl/7278043
The test case of issue 4585 was not passing due to
miscalculation of memequal args, and the previous fix
does not handle padding at the end of a struct.
Handling of padding at end of structs also fixes the case
of [n]T where T is such a padded struct.
Fixes#4585.
(again)
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7133059
The linker split PKGDEF into (prefix, name, def) pairs,
and defines def to begin after a space following the identifier.
This is totally wrong for the following export data:
func "".FunctionName()
var SomethingCompletelyUnrelated int
The linker would parse
name=`"".FunctionName()\n\tvar`
def=`SomethingCompletelyUnrelated int`
since there is no space after FunctionName.
R=minux.ma, rsc
CC=golang-dev
https://golang.org/cl/7068051
A constant node of type uintptr with a nil literal could
happen in two cases: []int(nil)[1:] and
uintptr(unsafe.Pointer(nil)).
Fixes#4614.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/7059043
Unnamed types like structs with embedded fields can have methods.
These methods are generated on-the-fly by the compiler and
it may happen for identical types in different packages.
The linker must accept these multiple definitions.
Fixes#4590.
R=golang-dev, rsc
CC=golang-dev, remy
https://golang.org/cl/7030051
Before this CL, defining the variable worked fine, but then when
the implicit package-level init func was created, that caused a
name collision and a confusing error about the redeclaration.
Also add a test for issue 3705 (func init() needs body).
Fixes#4517.
R=ken2
CC=golang-dev
https://golang.org/cl/7008045
Ordinary variable load was assumed to be not worth saving,
but not if one of the function calls later might change
its value.
Fixes#4313.
R=ken2
CC=golang-dev
https://golang.org/cl/6997047
The patch makes the compile user an ordinary package-local
symbol for the name of embedded fields of builtin type.
This is incompatible with the fix delivered for issue 2687
(revision 3c060add43fb) but fixes it in a different way, because
the explicit symbol on the field makes the typechecker able to
find it in lookdot.
Fixes#3552.
R=lvd, rsc, daniel.morsing
CC=golang-dev
https://golang.org/cl/6866047
The typechecking code was doing an extra, unnecessary
indirection.
Fixes#4458.
R=golang-dev, daniel.morsing, rsc
CC=golang-dev
https://golang.org/cl/6998051
A fatal error used to happen when escassign-ing a multiple
function return to a single node. However, the situation
naturally appears when using "go f(g())" or "defer f(g())",
because g() is escassign-ed to sink.
Fixes#4529.
R=golang-dev, lvd, minux.ma, rsc
CC=golang-dev
https://golang.org/cl/6920060
I just committed a patch to gccgo that notices that float was
never defined, causing an additional unmatched error message.
Rename the type to avoid that message.
R=golang-dev, minux.ma
CC=golang-dev
https://golang.org/cl/6947049
This check for BADWIDTH might happen while in defercheckwidth, making it raise errors for non-erroneous situations.
Fixes#4495.
R=golang-dev, rsc
CC=golang-dev
https://golang.org/cl/6927043
Used to say:
issue4251.go:12: inverted slice range
issue4251.go:12: constant -1 overflows uint64
issue4251.go:16: inverted slice range
issue4251.go:16: constant -1 overflows uint64
issue4251.go:20: inverted slice range
issue4251.go:20: constant -1 overflows uint64
With this patch, only gives the "inverted slice range" errors.
R=golang-dev, daniel.morsing
CC=golang-dev
https://golang.org/cl/6871058
Fixes#4396.
For fixed arrays larger than the unmapped page, agenr would general a nil check by loading the first word of the array. However there is no requirement for the first element of a byte array to be word aligned, so this check causes a trap on ARMv5 hardware (ARMv6 since relaxed that restriction, but it probably still comes at a cost).
Switching the check to MOVB ensures alignment is not an issue. This check is only invoked in a few places in the code where large fixed arrays are embedded into structs, compress/lzw is the biggest offender, and switching to MOVB has no observable performance penalty.
Thanks to Rémy and Daniel Morsing for helping me debug this on IRC last night.
R=remyoudompheng, minux.ma, rsc
CC=golang-dev
https://golang.org/cl/6854063
The current spec says that when calling make, if both len and
cap are constant, it is an error if len > cap. The gc
compiler does not yet implement that, but when it does this
will need to change. Changing it now for the benefit of
gccgo.
R=gri
CC=golang-dev
https://golang.org/cl/6867064
