Hi all,

Am I the only one who has problems with the codetools? Seems like it can not handle out-parameters in functions anymore.

like this: (variants.pp)

function VarIsError(const V: Variant; out AResult: HRESULT): Boolean;

But there are many others in the RTL and FCL.

Or is it a local issue?

Regards,

Joost,

Joost van der Sluis wrote

Am I the only one who has problems with the codetools? Seems like it can not handle out-parameters in functions anymore.

What CT function is not working in particular?

I tested with:

program CTTest1;
uses
   SysUtils, Classes;
function VarIsError(const V: Variant; out AResult: HRESULT): Boolean;
begin
end;
begin
   x := VarIsError(v, s);
end.

and everything seems to be OK to me.

Or is your problem that CT cannot resolve what overload to use:
function VarIsError(const V: Variant; out AResult: HRESULT): Boolean;
function VarIsError(const V: Variant): Boolean; inline;

AFAIK CT have always had this issue to find correct overloads, so no regression here. (At least Lazarus 1.4.2 has the issue as well.)

Ondrej

That one works for me also. Now when I add Variants to the uses, nothing works anymore. (Try identifier-completion in VarIsError -> move cursor to VarIs -> ctrl-space)
Same happens when you add contnrs to the uses-section.

Do you also have that problem?

Regards,

Joost.

Works fine for me:

I am on current Lazarus trunk with FPC trunk r36463.

Ondrej
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20170613/c2710907/attachment.html> -------------- next part --------------
A non-text attachment was scrubbed...
Name: engcoadccedimplm.png
Type: image/png
Size: 8248 bytes
Desc: not available
URL: <http://lists.lazarus-ide.org/pipermail/lazarus/attachments/20170613/c2710907/attachment.png>

I don't get it. I have the same issue on two different systems. Both Lazarus- and FPC-trunk. For at least a week already...

This is what I see on the console:

Hint: [TFPCSourceCache.Update] /home/CNOC/joost/svn/fpc-trunk has changed. ApplyFPCSrcFiles BuildBoss.RescanCompilerDefines ... TFPCSrcScan.OnFilesGathered closing progress item ... TFPCSrcScan.OnFilesGathered END
### TCodeToolManager.HandleException: [20170421195425] "expected :, but AResult found" at Line=111 Col=43 in
"/home/CNOC/joost/svn/fpc-trunk/packages/rtl-objpas/src/inc/variants.pp" ### TCodeToolManager.HandleException: [20170421195348] "expected end., but AResult found" at Line=111 Col=43 in
"/home/CNOC/joost/svn/fpc-trunk/packages/rtl-objpas/src/inc/variants.pp" ### TCodeToolManager.HandleException: [20170421195348] "expected end., but AResult found" at Line=111 Col=43 in
"/home/CNOC/joost/svn/fpc-trunk/packages/rtl-objpas/src/inc/variants.pp"

etc etc

Any idea where to look?

Regards,

Joost.

Op 13-06-17 om 19:08 schreef Joost van der Sluis via Lazarus:

Seems like Lazarus has a compilermode-flag cmsOut, to indicate that a compiler supports out-parameters. This flag is not set.

At a closer look, the variants.pp unit starts with:

{$IFDEF FPC}
{$MODE objfpc}
{$H+}
{$ENDIF}

But when showed in Lazarus, {$MODE objfpc} is grayed out. So Lazarus does not detect that FPC is defined...

In the defines-editor, I do see the FPC-define, but I don't see any value. Is that normal?

Any clue why 'fpc' is not defined according to the codetools?

Regards,

Joost.

Joost van der Sluis wrote

Any clue why 'fpc' is not defined according to the codetools?

I have no idea :( I'll ping Mattias directly. I am quite sure he'll know what to look for from your information :)

Ondrej

This corresponds to the {$modeswitch out}.

No. The macro FPC comes from reading the compiler output. Try main menu
Tools / Rescan FPC Source Directory
to reread the compiler output.

Any clue why 'fpc' is not defined according to the codetools?

Open unit variants in source editor.
Main menu / Source / Unit information / Show Codetools defines In "Values" you should see a lot of defines, like VER3_1_1 and FPC.

Mattias

Op 14-06-17 om 10:09 schreef Mattias Gaertner via Lazarus:

Fixed, not in Lazarus, but fpc.

Why is it, that when I (working mostly on fpc) discover Lazarus-bugs, they almost always appear to be fpc-issues?

One would thing I should be able to recognize and handle fpc-bugs... ;)

Regards,

Joost.

Lazarus is a good test suite for fpc.

One would thing I should be able to recognize and handle fpc-bugs... ;)

May I ask what the bug was?

Mattias

Op 14-06-17 om 10:29 schreef Mattias Gaertner via Lazarus:

It's fixed in r36498 by Nikolay. It was a bug in the widestring-handling which was already there, but was hidden and got exposed by a recent change in the codepage-handling.

As a result #0-characters were added to fpc's output. Lazarus' parser got confused by that. (It uses pchar's, which considered the #0 characters the end of a line)

Regards,

Joost.