TELL: unrestricted overloading of functions is limited

[GoogleCodeExporter]

please, take a look to the attached files:
Although the contents, lets say the semantic, of the two files is identical the 
parser delivers different results. In one case (bug_fail.tll) the parser fails 
to  detect an overloaded function.

As a consequence, the succession of defining overloaded functions can not be 
chosen arbitrary.

best regards
armin

Original issue reported on code.google.com by analogc...@gmx.net on 7 Apr 2012 at 7:46

Attachments:

• bug_fail.tll
• bug_ok.tll

[GoogleCodeExporter]

I think I know where is the problem.

Original comment by krustev....@gmail.com on 9 Apr 2012 at 11:58

• Changed state: Assigned

[GoogleCodeExporter]

There are 3 problems with this actually.
1. The parser should not allow overloading of functions with different types. 
As in the examples 
real xy(...)
int xy(...)
should not be allowed. This is perhaps written in somewhere in the 
documentation, but the parser doesn't have a check whatsoever. Suppose we 
forget about it, then there are two more problems 
2. First with the "fail" case - when xy(real, real) comes first, when the 
parser is checking whether xy(int, int) already exists, the check returns 
"exists" because of the build-in conversion int->real. So in this case, the 
first declaration is simply replaced by the second one - hence can never be 
called. (you can see the warning in the log)
3. When xy(int,int) comes first and the parser checks whether xy(real,real) 
already exists - the check returns properly "not existing", so the new 
definition is added. The funny part in this case however is when xy(int,int) is 
called. As it is now the parser could call any of the definitions (again 
because of the build-in conversion int-real). It is up to the underlying 
implementation of std::multimap<> that (on my platform) xy(int,int) pops up 
first. If xy(real,real) is found first - then the int version will be 
overshadowed and will never be called.

All the above is to say that the fix requires serious checks and a bit of a 
discussion. I would postpone the fix and will do it after the 0.9.8 release.

Original comment by krustev....@gmail.com on 14 Apr 2012 at 2:12

[GoogleCodeExporter]

The bulk if the issue fixed in r2147 - r2148. Needs further validation

Original comment by krustev....@gmail.com on 6 May 2012 at 12:52

[GoogleCodeExporter]

The updates listed above appears to be stable.

Original comment by krustev....@gmail.com on 12 May 2012 at 1:30

• Changed state: Fixed

[GoogleCodeExporter]

Original comment by krustev....@gmail.com on 13 May 2012 at 8:16

• Changed state: Verified