[Lazarus] Lazarus in trunk not working after Rev 50151 on MacOSX

[Ondrej Pokorny]

Fixed in r50217.

On 04.11.2015 02:14, Mattias Gaertner wrote:
>> A problem could be with such code:
>> >
>> >var
>> >    i: SizeInt;
>> >    j: Integer;
>> >begin
>> >    k:=i+j;
>> >end;
>> >
>> >Because obviously on 32bit SizeInt=longint and Integer=longint, so there
>> >won't be a deterministic way which type wins.
> Left side wins.
> It can't be perfect, but it should be deterministic.

SizeInt always wins - both if it is on left side or right side because 
it has a higher rank than Integer. So it is now completely deterministic.
(Under "not deterministic" I ment that "k:=i+j" and "k:=j+i" return 
different types, which is the case of "left side wins".)

On 04.11.2015 05:42, Ondrej Pokorny wrote:
> On 04.11.2015 02:25, Mattias Gaertner wrote:
>>> About the table:
>>> >We need one table for integer and one for floating-point types.
>>> >The integer table could look like ['int64', 'sizeint', 'integer',
>>> >'smallint'] (but with all integer types and probably a good idea to
>>> >allow the user to modify and enhance it - e.g. a simple TStringList).
>>> >The winner is the one closest to the left (top - smallest index).
>> Many libs has such types. I have not counted, but I guess the FPC
>> sources has hundreds of them. Probably some of them conflict each other.
>> So something better than a TStringList should be used.
>
> Could you tell which one to use?

Ok, I used just a simple "array of string". It's not the fastest/best 
for adding items one-by-one but there are not so many types, so who 
cares... It can be easily replaced if you don't like it.

+ I may have not added all predefined types in:
function BooleanTypesOrderList: TTypeAliasOrderList;
function IntegerTypesOrderList: TTypeAliasOrderList;
function RealTypesOrderList: TTypeAliasOrderList;
function StringTypesOrderList: TTypeAliasOrderList;

you are welcome to extend them.

Ondrej