GNU Pascal Homepage - gpc - gpc-announce - gpc-de - gpc-doc
Diese Seite auf deutsch

Mail #49

Back to main page of archive

Previous mail   Next mail   Unformatted/full headers
Overview  10 days   Subject   Date   Thread   Author  

From: Grant Jacobs
Subject: Weird type/identifier conflicts
Date: 28 Feb 2003, 12:24:33

Excuse my being frustrated. I am trying damn hard to get GPC (2.1 
(20020510), based on gcc-2.95.3 20010315 (release)) to compile a 
Pascal program I wrote some time ago but keep running it things I 
can't make sense of. Maybe I'm being unfair, but I'll give you the 
whole story just in case its something new. The latest issue I'm 
having is a run of type vs. identifier conflict errors of the form:


./GHJ_AARegions.pas:49: type name expected, identifier `Fnames' given
./GHJ_AARegions.pas:49: warning: missing type in declaration of `Infname'
./GHJ_AARegions.pas:54: warning: parameter has incomplete type


My trouble was fnames *is* a type. It is *only* defined as a type. So 
how the heck does the compiler come away thinking that its an 
identifier?????

I eventually resolved this by directly 'using' modules, rather than 
rely on the hierarchy (read on).

When this error occurred the GHJ_AARegions unit uses GHJFnames. 
GHJFnames in turn uses GHJFiles, which is where the type fnames is 
defined. (Really these two levels need to be the other way around, 
but this is a legacy program I am porting, so I have to deal with 
that after the port.)

Since these uses statements were within the interface section, I 
presumed the definitions would propagate upwards so that they form a 
hierarchy. Or, put another way, I assumed the interface of a unit is 
extended by any units it uses in its interface section.

Originally, I had:


unit GHJ_AARegions ;

{
       Holds routines for dealing with the region indicies.
}

interface

uses GHJStdDefs, GHJStdMaths { for inrange() },
      GHJttInterface { for press_return() },
      {GHJTextIO} { for skip_aa_comments() } {,}
      GHJStrings { for get_string8() },
{=>} GHJFnames { for get_fname() },
      GHJ_AAErrors, GHJ_AAUtils, GHJ_AAGlobalUnit ;


By getting GHJ_AARegions to explicitly, directly, use GHJFiles, the 
compiler stopped complaining. ie. I changed the above code to:


unit GHJ_AARegions ;

{
       Holds routines for dealing with the region indicies.
}

interface

uses GHJStdDefs, GHJStdMaths { for inrange() },
      GHJttInterface { for press_return() },
      {GHJTextIO} { for skip_aa_comments() } {,}
      GHJStrings { for get_string8() },
{=>} GHJFiles, GHJFnames { for get_fname() },
      GHJ_AAErrors, GHJ_AAUtils, GHJ_AAGlobalUnit ;


{=>} points out the offending line of source. If this is truly the 
problem, then I presume there is no way of building a hierarchy of 
units in GPC at present? (In this case my safest strategy is to have 
every unit uses *all* the lower units directly, "just in case". Or 
put, another way, I might just as well use includes to make 
everything one big flat program. Sorry, but I *am* frustrated!)


Three thoughts:

1. This is the correct behaviour?: surely I should be able to use a 
higher-level module and have all the lower-level modules definitions 
within that higher-level module "gotten" at the same time without 
have to explicitly duck behind the scenes and drag out each module??? 
Excuse me for asking this, but its not terribly clear from the docs, 
at least on my reading of it.

2. Why the heck does the compiler report the message it does? 
"Missing type fnames" perhaps, but since fnames is only ever defined 
as a type and never as an identifier, it shouldn't be able to report 
the message it did...

3. Is there any chance you can tell the user where the "identifier" 
(see the error message) is defined so that in future users might have 
chance of trying to second-guess just what the compiler is "thinking"?

Sorry I can't provide a full code example: I am porting a largish 
program (approx. 60,000 lines of sources in a dozen or so modules) 
and in any event I can't understand the problem well enough to create 
an example - catch-22...

Looking at the known bugs for ver. 2.1 there are a couple that might 
be relevant, esp."Types declared in a module interface are not 
visible in the implementation" (but does this refer to the same 
module's interface section and how are units and modules related with 
reference to this?)

While I'm writing, is there any chance you can make the compiler keep 
trying after one unit has failed, rather than stopping at that point? 
It seems that if there is even one error in a unit, the compilation 
is abandoned at the end of that unit.

(Now to try figure out how GPC claims a type-mismatch on something 
that is definitely the same type and the type is only defined in one 
place... probably the same issue, we'll see...)

Grant

Previous mail   Next mail   Unformatted/full headers
Overview  10 days   Subject   Date   Thread   Author  


Replies

Author Subject Date
Grant Jacobs Weird type/identifier conflicts 28 Feb 2003, 14:53:20

In reply to

Author Subject Date
Richard D. Jackson More on documentation tool 22 Feb 2003, 12:21:18
Frank Heckenbach More on documentation tool 27 Feb 2003, 19:53:21

Back to main page of archive


Note: This page contains information that does not originate from the owner of this web site, but from the authors of the mails archived. The owner of this web site is not responsible for the content of such information. Any use of that infomation requires the consent of the respective author.

Where WWW addresses (URLs) in the mails archived are marked as hyperlinks, this is only for the comfort of the reader. The content of the web pages linked to like this does not necessarily reflect the opinion of the owner of this web site or of the authors of the mails archived. The owner of this web site is not responsible for the content of such web pages. Those pages are explicitly not to be considered as part of the content of this page, but merely as references.


This page was created by Crystal 0.999 (Linux 2.4.27/i686).