<p dir="auto">by <strong>nautigar</strong>:</p>
<pre class="notranslate">In the section on Variable Declarations, the spec says:

If the type is absent and the corresponding expression evaluates to an untyped constant,
the type of the declared variable is as described in §Assignments.

In the Assignments Section, the only relevant paragraph on types says: 

If an untyped constant is assigned to a variable of interface type or the blank
identifier, the constant is first converted to type bool, rune, int, float64, complex128
or string respectively, depending on whether the value is a boolean, rune, integer,
floating-point, complex, or string constant.

Example 1

const a = 100
var i interface{} = a

According to the spec cited above, the dynamic type of i is int. No problem.

Example 2

const a = 100
var v = a

The spec does not cover this case. How is the type of v determined?

Example 3

const a = 5000000000
var v = a

More serious problem here: Is this allowed? (playground experiment says no).
If yes, what should be the type of v (int64, uint64?). The spec does not cover this case.</pre>
<p dir="auto">by <strong>awpritchard</strong>:</p>
<pre class="notranslate">Before filing a bug, please check whether it has been fixed since
the latest release: run "hg pull -u" and retry what you did to
reproduce the problem.  Thanks.

What steps will reproduce the problem?
1. Apply the patch attached as "patch" to an empty directory (creates 1.go,
2.go, Makefile)
2. run 'make'

-OR-

1. Create two cgo source files and refer to one C struct in both files, and one C struct
whose name is alphabetically before the previous C struct, in only one of the files.
2. Create the standard Makefile for this situation, with Make.inc, Make.pkg, and
CGOFILES=
3. run 'make'

What is the expected output?
The package compiles correctly and without warnings.

What do you see instead?
cgo emits a warning about inconsistent definitions for the struct included in both cgo
files (in this case, 'XRectangle')

Which compiler are you using (5g, 6g, 8g, gccgo)?
6g

Which operating system are you using?
linux

Which revision are you using?  (hg identify)
3e8c5af7bb1a tip

Please provide any additional information below.
One way I can see this being solved is by identifying the _Ctype_struct___* definitions
by a hash of their C declarations, such that structs originating from the same C source
will be given the same name, regardless of the presence of other structs in the file,
and the warning will not be generated.  I have attached a patch ("cgo.patch")
with a naive implementation of this suggestion using the crypto/md5 package.  This
resolves the issue in my minimal example as well as in the actual package I originally
encountered the problem in, but may have performance issues compared to the original
implementation, as it calculates a cryptographic hash of every struct name used.</pre>
<p dir="auto">Attachments:</p>
<ol dir="auto">
<li><a href="https://storage.googleapis.com/go-attachment/1264/0/patch" rel="nofollow">patch</a> (779 bytes)</li>
<li><a href="https://storage.googleapis.com/go-attachment/1264/0/cgo.patch" rel="nofollow">cgo.patch</a> (642 bytes)</li>
</ol>