An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160111/e896b984/attachment.html>

Isn't it possible anymore to compile svn Lazarus with fc 2.6.4 ??

No. Latest stable is the only one that's supported, latest stable is 3.0.0.

> Isn't it possible anymore to compile svn Lazarus with fc 2.6.4 ?? No. Latest stable is the only one that's supported, latest stable is 3.0.0.

FPC 3.0.0 is still fresh. We should try to give users some more time to port their software.

In this particular case RawByteString is not needed and not intended. It probably was created by auto completion of

xIconFiles|:=ChangeFileExt();

Code completion needs a heuristic when to use String (or maybe AnsiString) instead of RawByteString.

Mattias

[...] Kompiliere Package IDEIntf 1.0: Exit code 1, Fehler: 4, Hinweise: 1 projectintf.pas(708,14) Error: Identifier not found "RawByteString"

Fixed.

Mattias

leledumbo wrote

> Isn't it possible anymore to compile svn Lazarus with fc 2.6.4 ?? No. Latest stable is the only one that's supported, latest stable is 3.0.0.

Actually we plan to keep Lazarus compilable with FPC 2.6.4 for some time. Typically it should support 2 last versions of FPC. It would mean that 2.6.4 is dropped when 3.0.2 comes out.
Now however the new UTF-8 system breaks existing code when it depends on system codepage on Windows. One way to solve the problem is to continue using FPC 2.6.4. Lazarus compilation for 2.6.4 can be maintained relatively easily. No need to break it anytime soon.

The problematic commit was r51233 by Ondrej. I planned to fix it but Mattias did already.

Juha

Mattias Gaertner wrote

In this particular case RawByteString is not needed and not intended. It probably was created by auto completion of xIconFiles|:=ChangeFileExt();

Correct. It wasn't definitely intended. I'll be more careful when using Code Completion.

Mattias Gaertner wrote

Code completion needs a heuristic when to use String (or maybe AnsiString) instead of RawByteString.

I think it fails to find exact overloads.

Ondrej

There is no overload. There is only one definition:

{$define PathStr:=RawByteString}
function ChangeFileExt(const FileName, Extension: PathStr): PathStr;

Note to self: it would be nice if Find Declaration would jump to the macro definition of PathStr.

Mattias

On Mon, Jan 11, 2016 at 10:32 AM, Mattias Gaertner <

why not
type
PathStr= RawByteString; ?

thanks,
Dmitry
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus.freepascal.org/pipermail/lazarus/attachments/20160111/7103056c/attachment.html>

Poor mans generics, re-reading the same include file with different definition of
{$define PathStr:=RawByteString}

Michael.

Good question. Maybe ask on the FPC list.

Mattias

Mattias fixed and therefore i can compile Lazarus at home ( problem occured in office today )?!!

I'll see tomorrow.

Thanks in advanced :-))

John Landmesser

finah.inc is loaded twice with different PathStr macro so there are effectively 2 overloaded ChangeFileExt.

The issue can be easily reproduced (try to complete X):

function StrFunc(Str: string): string;
begin
   Result := Str;
end;
function StrFunc(Str: RawByteString): RawByteString;
begin
   Result := Str;
end;
procedure Test;
var
   R: RawByteString;
   S: string;
begin
   X := StrFunc(S);
end;

This is because both string and RawByteString have the same default type (AnsiString) in CodeTools.

The same is for numbers (and any other type defined with "child = type parent"):

type
   PtrInt = type Longint;
function NumFunc(Num: PtrInt): PtrInt;
begin
   Result := Num;
end;
function NumFunc(Num: Integer): Integer;
begin
   Result := Num;
end;
procedure Test;
var
   I: Integer;
   P: PtrInt;
begin
   X := NumFunc(P);
end;

=> CodeTools fail to find the exact matching overload if there is another less good (but still acceptable) overload. CodeTools are fine when they found one compatible overload, not the best that is actually picked up by the compiler.

Are you aware of this bug (or are you aware of an issue report in mantis)?

Ondrej

[...] finah.inc is loaded twice with different PathStr macro so there are effectively 2 overloaded ChangeFileExt.

You are right.

I'm aware. Codetools have only three states: exact, compatible and incompatible. But in case of RawByteString and UnicodeString one "compatible" is not enough.

Mattias

Mattias Gaertner wrote

I'm aware. Codetools have only three states: exact, compatible and incompatible. But in case of RawByteString and UnicodeString one "compatible" is not enough.

This is somehow not entirely correct (I haven't checked why). The integer example I gave in the last email also fails. That should comply with the "exact" state (PtrInt used both as variable and overload parameter).

Maybe the desired behavior (match for exact state) has a bug as well.

Ondrej