View Issue Details Jump to Notes ] Issue History ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0014104FPCCompilerpublic2009-07-05 19:582010-03-06 21:33
ReporterSteve Miller 
Assigned ToJonas Maebe 
PrioritynormalSeverityminorReproducibilityalways
StatusclosedResolutionfixed 
PlatformWindowsOSXPOS Version
Product Version2.2.4Product Build 
Target VersionFixed in Version2.4.0 
Summary0014104: Forward declaration not solved if we redefine InitGraph in the interface of a Unit
DescriptionOld source code now with ver 2.2.4 gives "Forward declaration not solved" error when compiling a unit that compiled fine under 2.2.1
(see attached sample)

The unit redefines a procedure of unit graph.
Steps To ReproduceThe attached (simplified) unit does not compile.
Additional InformationI found a work around: move the uses clause into the interface section. (But I understand that there are some drawbacks to this.)

I wonder how much this is related to bug 11435/11436 and 10540.

Strange this is that only redefining procedures/functions of the unit Graph seem having that problem; I tested a few from DOS and SYSUTILS and for them I could keep the uses clause in the implementation section.
TagsNo tags attached.
FPCOldBugId
Fixed in Revision13373
Attached Files? file icon grhelp.PAS [^] (335 bytes) 2009-07-05 19:58
? file icon filehelp.PAS [^] (207 bytes) 2009-07-08 20:18

- Relationships

-  Notes
(0028981)
Steve Miller (reporter)
2009-07-08 20:18

I encountered a problem that very likely is related to the above.

Overloading Write(var f:file of extended;e:extended) via a unit also causes a "Forward declaration not solved" error. (see the attached file filehelp.pas) But here we cannot use the above work around as including the SYSTEM unit isn't allowed. (I was hoping the -Us switch would help, but it doesn't)

IIRC in the TP days you could extract and unload the system unit from the TURBO.TPL with the TPUMOVER tool which then forced you to add the system unit to the uses list - but I didn't want to dig into the equivalent version here.

The work around here is to rearrange your source code and bring the overloaded procedure into the main program. Rather annoying IMHO.
(0028987)
Jonas Maebe (manager)
2009-07-08 22:24

The original problem was due to the graph unit defining its own smallint type. The result was that the definition in the interface used system.smallint as parameter type, while the one in the implementation used graph.smallint. I've removed the smallint type from the graph unit to solve this.

The problem in your second example is due to the use of "file of extended" inside the parameter list. This results in two separate type definitions, one in the interface and one in the implementation. You can fix it by defining a single "type extendedfile = file of extended;" and using that one in your parameter list. You get the same sort of error if you use e.g. string[5] as a parameter type.

Kylix refuses to compile programs containing that kind of definitions inside parameter lists, probably because it is not possible to compile such code without violating Pascal semantics (whereby types are not considered to be the same simply because they are semantically the same, but only when they are actually the same type definition).

I've now fixed FPC so that it also properly rejects such parameter type definitions. See http://wiki.freepascal.org/User_Changes_Trunk#Local_type_definitions_in_parameter_lists [^] for more information.
(0029001)
Jonas Maebe (manager)
2009-07-09 11:28

By the way: you can work around the smallint redefinition problem by using the following declaration in the implementation of your unit:

procedure initGraph(var gd:system.smallInt; var gm:system.smallInt;mypath:string);

- Issue History
Date Modified Username Field Change
2009-07-05 19:58 Steve Miller New Issue
2009-07-05 19:58 Steve Miller File Added: grhelp.PAS
2009-07-08 20:18 Steve Miller File Added: filehelp.PAS
2009-07-08 20:18 Steve Miller Note Added: 0028981
2009-07-08 22:24 Jonas Maebe Fixed in Revision => 13373
2009-07-08 22:24 Jonas Maebe Status new => resolved
2009-07-08 22:24 Jonas Maebe Fixed in Version => 2.3.1
2009-07-08 22:24 Jonas Maebe Resolution open => fixed
2009-07-08 22:24 Jonas Maebe Assigned To => Jonas Maebe
2009-07-08 22:24 Jonas Maebe Note Added: 0028987
2009-07-09 11:28 Jonas Maebe Note Added: 0029001
2010-03-06 21:33 Jonas Maebe Status resolved => closed



MantisBT 1.2.12[^]
Copyright © 2000 - 2012 MantisBT Group
Powered by Mantis Bugtracker