From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 1 Jul 93 16:22:45 GMT
From: rochester!news.crd.ge.com!e7sa!groleau@louie.udel.edu
Subject: lint-like tool for Ada
Message-ID: <C9Huty.99t@crdnns.crd.ge.com>
List-Id: <comp.lang.ada>

I would be satisfied with a mere cross-reference generator.  I found ONE in
the PAL (formerly ASR) by using archie for "xref" and "cross-ref".  It's 
written in Pascal and I can't find a Pascal compiler on our system.

I could translate it to Ada, but it parses and xrefs a SINGLE file and
reference locations are line numbers.  It also apparently does not distinguish
between declarations, assignments, calls, etc.  or between overloaded names.

I'm looking for something like

   package X
         with'ed by B.S
         with'ed by B.T
         use'd by B.T

   function B.F
         declared in B
         called by B.S

   variable B.V
         declared in B
         assigned in B
         assigned in B.S
         examined in B.T

File names/line numbers would be icing on the cake.  I need it for the same
reason as the other posters--to remove or move to lower levels withs, uses, 
objects, etc. that are not used at a particular level and are causing
1. loads of unnecessary recompilations
2. tremendous obscurity in unfamiliar code.

It's not sufficient for me to just search one file at a time for "is this
referenced?" because I need to find out what goes where to re-design.  I have
inherited code that is partitioned by "shape"  by which I mean
  Author: "OK, at the top of this package are all the messages, and at
           the bottom of that one are all the pointers to the messages.
           Over here we have the instantiations of a queue for each message,
           and ...."
  Me:     "Why didn't you put all the messages to the blue box, and their
           pointers and queues in the one package, and those for the red box
           in another?"
  Author: "What would that buy?"
  Me:     "1. You wouldn't have to recompile ALL files when something changes
              in the red box.
           2. I could understand any particular package without having to
              understand the entire million-lines-of-code project.
           3. I could understand a subprogram without having to bounce around
              thirteen files of declarations."
  Boss:   "Insights like that are the reason we put you on this job, Wes!"

Unfortunately, the "author" is long gone and I have to substitute long-hours
of eyeball work.

Wes Groleau