Mailing-List: contact etch-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: etch-dev@incubator.apache.org
Received-SPF: pass (nike.apache.org: domain of sccomer@cisco.com designates
 171.71.176.71 as permitted sender)
Message-ID: <4978D52C.7040607@cisco.com>
Date: Thu, 22 Jan 2009 14:21:00 -0600
From: scott comer <sccomer@cisco.com>
Reply-To: etch-dev@incubator.apache.org
User-Agent: Thunderbird 2.0.0.19 (Windows/20081209)
MIME-Version: 1.0
To: etch-dev@incubator.apache.org
Subject: [vote]: (ETCH-27) mixins cause trouble when two or more mixed in
 files define a type with the same name.
References: <592282763.1232489819792.JavaMail.jira@brutus>
In-Reply-To: <592282763.1232489819792.JavaMail.jira@brutus>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

[no discussion, time to vote. 48 hrs. -scott]

https://issues.apache.org/jira/browse/ETCH-27

i want to include this fix in release 1.0.2.

wei found this bug on friday. consider these etch files:

-------------
module foo
service Foo
{
    mixin Bar
    mixin Baz
}
-------------

-------------
module bar
service Bar
{
    struct Entry( int x )
    void barGet( Entry e )
}
-------------

-------------
module baz
service Baz
{
    struct Entry( int x )
    void bazGet( Entry e )
}
-------------

this should be good, because bazGet should refer to its own Entry and
barGet to its own, too. but the compiler started the name search for
Entry in barGet at the top of the module tree (Foo) instead of in Bar.
by starting at the top, it found two Entry definitions, bar.Entry and
baz.Entry. not being able to distinguish between them, it declares them
ambiguous and ultimately fails.

rather, when barGet is being compiled, the search for Entry should start
with Bar. in the name checking section of the compiler it already does
just that. this fix just fixes name resolution in Compiler.java to work
the same way.