Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2020-05

Code tools unrelated completions

6 messages · 3 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Ryan Joseph

Code tools completions are returning functions that don't appear related to the current unit such as "fpc_Copy" from /usr/local/share/fpcsrc/rtl/inc/compproc.inc.

Here's a snippet of the code I use to get identifiers.

      if CodeToolBoss.GatherIdentifiers(Code,X + 1,Y + 1) then
        begin
          Count := CodeToolBoss.IdentifierList.GetFilteredCount;
          for I := 0 to Count - 1 do
            begin
              Identifier := CodeToolBoss.IdentifierList.FilteredItems[I];

Is this normal to be getting these results? I'd like to not have them if possible.

Regards,
Ryan Joseph

Reply by email

Michael Van Canneyt
to Ryan Joseph
Ryan Joseph wrote 14 lines
Code tools completions are returning functions that don't appear related to the current unit such as "fpc_Copy" from /usr/local/share/fpcsrc/rtl/inc/compproc.inc. Here's a snippet of the code I use to get identifiers. if CodeToolBoss.GatherIdentifiers(Code,X + 1,Y + 1) then begin Count := CodeToolBoss.IdentifierList.GetFilteredCount; for I := 0 to Count - 1 do begin Identifier := CodeToolBoss.IdentifierList.FilteredItems[I]; Is this normal to be getting these results? I'd like to not have them if possible.

They are in the system unit, so they're always related to any unit.

They have a compilerproc modifier set, so I suppose there is some property/attribute of the identifier that indicates this modifier. You should check for that and filter out these results.

Michael.

Reply by email

Ryan Joseph
to Michael Van Canneyt
Show quoted text 7 lines
On May 5, 2020, at 3:56 PM, Michael Van Canneyt wrote: They are in the system unit, so they're always related to any unit. They have a compilerproc modifier set, so I suppose there is some property/attribute of the identifier that indicates this modifier. You should check for that and filter out these results.

AFAIK they are not meant to be called by users so I'd like to filter them out.

how do we get function modifiers for TIdentifierListItem then?

Regards,
Ryan Joseph

Reply by email

Michael Van Canneyt
to Ryan Joseph
Ryan Joseph wrote 13 lines
> On May 5, 2020, at 3:56 PM, Michael Van Canneyt wrote: > > They are in the system unit, so they're always related to any unit. > > They have a compilerproc modifier set, so I suppose there is some > property/attribute of the identifier that indicates this modifier. > You should check for that and filter out these results. AFAIK they are not meant to be called by users so I'd like to filter them out. how do we get function modifiers for TIdentifierListItem then?

I have no idea. This is a question for Mattias.

But , line 1988 I think I may have been too
optimistic;
    end else if UpAtomIs('COMPILERPROC') then begin
       ReadNextAtom;
       if CurPos.Flag=cafColon then begin
         // e.g. compilerproc:fpc_in_delete_x_y_z;
         ReadNextAtom;
         AtomIsIdentifierSaveE(20180411194104);
         ReadNextAtom;
       end;

it's handled but not recorded.

Michael.

Reply by email

Mattias Gaertner
to Michael Van Canneyt
Show quoted text 33 lines
On Tue, 5 May 2020, Ryan Joseph via fpc-pascal wrote: > > >> On May 5, 2020, at 3:56 PM, Michael Van Canneyt >> wrote: >> >> They are in the system unit, so they're always related to any unit. >> >> They have a compilerproc modifier set, so I suppose there is some >> property/attribute of the identifier that indicates this modifier. >> You should check for that and filter out these results. > > AFAIK they are not meant to be called by users so I'd like to > filter them out. > > how do we get function modifiers for TIdentifierListItem then? I have no idea. This is a question for Mattias. But , line 1988 I think I may have been too optimistic; end else if UpAtomIs('COMPILERPROC') then begin ReadNextAtom; if CurPos.Flag=cafColon then begin // e.g. compilerproc:fpc_in_delete_x_y_z; ReadNextAtom; AtomIsIdentifierSaveE(20180411194104); ReadNextAtom; end; it's handled but not recorded.

Yes, recording is a todo.
If you want to check this you have to use the parsing functions like ProcNodeHasSpecifier or MoveCursorToProcSpecifier.

Mattias

Mattias

Reply by email

Ryan Joseph
to Mattias Gaertner
Show quoted text 5 lines
On May 5, 2020, at 4:35 PM, Mattias Gaertner via fpc-pascal wrote: Yes, recording is a todo. If you want to check this you have to use the parsing functions like ProcNodeHasSpecifier or MoveCursorToProcSpecifier.

Why don't the nodes keep track of this information btw? That was the first place I got confused by since I expected them to have lots of meta data along with them.

Regards,
Ryan Joseph

Reply by email