current xlint++ specs

[Mark S. Miller <mark>]

Date: Sun, 4 Feb 90 19:17:14 PST
   From: roland@xanadu (Roland King)

    This is the current list of things that xlint++ should catch.
    Let me know of any that can go away or any that I've missed.

Here goes:

     2) non COPY classes between two COPY classes in
	an inheritance chain

    13) PROXY classes w/out virtual destructors

    21) misplaced NOWAIT: NOWAIT should only occur in a PROXY section
	as a DEFFERED_SUBR overloadings of it in subclasses should have 
        no output args

XLint should still check for these unless it would be easy for the
formic script in stubble to do so instead.  Wjr?  Mr. Hill?

Also, I think #21 should read:

21) misplaced NOWAIT: NOWAIT should only occur in a PROXY section as a
DEFFERED_SUBR and should have no output args.

As far as redefinitions in subclasses are concerned, see #36 below.  I
assume you meant redefinitions and not overloadings?  (overloadings
are essentially unrelated functions having the same name)

     6) all DEFERRED FUNCTIONS should be VIRTUAL

No longer necessary.  On compilers in which the "pureVirtualBug" has
been fixed, we expand DEFERRED_FUNC and DEFERRED_SUBR to "= 0".  The
2.0 compiler understands that this means that this function is a pure
virtual function and probably insists on the virtual declaration
(please check this, though).

     7) DEFERRED member functions which aren't redefined on the path
	to all concrete subclasses (a concrete subclass is a subclass
	without a DEFERRED section.)

No longer necessary for a similar reason.  The 2.0 compiler treats any
class with a pure virtual function as an abstract class.  If Foo's
superclass has any pure virtual functions, then Foo must provide
declarations for those functions--either as pure virtuals also, or as
real declarations.

    16) an attempt to directly instantiate a DEFERRED class.

No longer necessary.  The 2.0 compiler prevents direct instantiation
of abstract classes.

    10) single argument constructors
    11) global variables
    12) static local variables
    15) pointer arithmetic
    18) assignment to "this"
    22) CLASS - DEFINE_CLASS type mismatch
    25) assignment to a parameter variable in function body
    31) pointers to functions

Not generatable from Smalltalk.  We still need to check for these
eventually, but they are currently of lower priority.
Smalltalk/translator gurus: please confirm that none of the above can
be generated from Smalltalk, and that everything else on Roland's list
can. 

    17) destructor in class w/ no constructor

I believe 2.0 already warns about this.  Also, I don't see why either
they or we should warn about this.  It seems fully non-problematic to
me.  Even if they don't warn, I think we shouldn't.

    19) assignments between pointers-to-pointers
	which don't point at the same exact type

2.0 may check for this now.  Please check.

    27) NOT_TYPE CLASS(EQObject,Object) used in a type declaration
	(Question: does this only exclude 'typedef EQO foo;' or also
	 'EQO foo;' If the latter, how does such a class get used ?)

EQObject (and similar NOT_TYPE classes) get used only to be
subclassed, not in declarations.  We need this check (even though we
should get rid of EQObject).

    28) Clasess implementing isEqual using object identity (pointer
	comparison) passed by COPY ()* it must be pass by PROXY **)

Still needed (in fact, it would have caught a bug that I spent a week
tracking down a few ages ago).  Btw, What do the "*"s and ")"s
signify? 

    30) unstublifiable member ( All instance vars in COPY sections &
	all function arguments in PROXY sections must be STUBLIFIABLE.
	A class is stublifiable iff	1) it has a COPY section or
	2) it has a PROXY section or 3) it has a DEFERRED section &
	all its immediate children are stublifiable.
	(Question: what about non-class types ?) 

XLint should not complain about non-class types.  When these aren't
stubblifiable, that fact will be caught immediately either by Stubble,
or when we compile the Stubble output.


All those I didn't mention still need to be checked by XLint.


Missing:

32) One should never use "= 0;" itself to indicate pure virtual
function.  Instead, one should use either DEFERRED_FUNC or
DEFERRED_SUBR.  This is low priority, as it can go away should 2.1 fix
the pureVirtualBug, and should 2.1 become widespread.  Should these
happen, we should globally replace DEFERRED_FUNC & DEFERRED_SUBR with
"= 0" in our code, retire these macros, and have our tools (e.g. XLint
and Formic) treat "= 0" as it used to treat these macros.

33) This would be a big deal: Have XLint understand the OFn macros and
do type checking of the program according to parameterized type rules.
An important open question is: *Whose* parameterized type checking
rules?  Please postpone this one at least until we have the time to
think seriously about types (and read Pavel Curtis's thesis).

34) Once #33 exists, then XLint should allow hard casts that it can
prove to be type safe, and warn about uses of the CAST macro where it
would have approved of a hard cast.

35) member object initialization in a class with a constructor bomb.
More sophisticated would be to allow this if the member object's
constructor has no constructor bomb (given that we also do #2 below).
This would prevent us from running into Michael's recently reported
unfixable BOMB package bug.

36) There are plenty of interesting rules we could impose on proper
use of output arguments (e.g. to check that they are in fact only used
*as* output arguments, and that redeclarations in subclasses declare
outputs indentically).  However, we currently don't use any, so this
can wait indefinitely.


There are also those things that X4ref should check for (instead of
XLint because they are properties of a program and not of a module):

1) member function delared virtual and *not* redeclared in any
subclass.  (should be LEAF)

2) uncaught blast emanating from a constructor that doesn't have a
constructor bomb

3) uncaught blast emanating from any destructor

4) uncaught blast emanating from a BOMB action (note that uncaught
blasts emanating from a BLAST_SHIELD action are fine)