Re: [gobo-eiffel-develop] CATCALLs when running tests via geant

[Colin P. A. <co...@co...>]

Forwarded:
>>>>> "Colin" == Colin Paul Adams <co...@co...> writes:

>>>>> "Eric" == Eric Bezault <er...@go...> writes:
    Eric> Colin Paul Adams wrote:
    >>> I'm trying to run the xslt tests using geant test_debug_ge,
    >>> and I'm getting a lot of messages identical to this one:
    >>> 
    >>> [CATCALL] class TUPLE [NATURAL_32, INTEGER] (ANY,97,8): type
    >>> 'NATURAL_16' of actual argument #1 does not conform to type
    >>> 'INTEGER_16' of formal argument in feature `is_equal' in class
    >>> 'INTEGER_16'
    >>> 
    >>> 
    >>> as well as many other CATCALL messages.
    >>> 
    >>> How do I get additional information to try to track down the
    >>> problems?

    Eric> Use gelint with the --catcall option.

    Colin> That meant I was easily able to eliminate my node-iterator
    Colin> agent problems, but I'm at a loss as to know what to make
    Colin> of stuff like this:

    Colin> [CATCALL] class TUPLE [NATURAL_32, INTEGER] (ANY,97,8):
    Colin> type 'NATURAL_32' of actual argument #1 does not conform to
    Colin> type 'INTEGER_32' of formal argument in feature `is_equal'
    Colin> in class 'INTEGER_32': Target type: 'INTEGER_32' Attachment
    Colin> stack #1 class TUPLE [NATURAL_32, INTEGER] (ANY,97,8):
    Colin> target class TUPLE [NATURAL_32, INTEGER] (267,25): argument
    Colin> class TUPLE [NATURAL_32, INTEGER] (56,39): assignment class
    Colin> TUPLE [NATURAL_32, INTEGER] (60,2): built-in Attachment
    Colin> stack #2 class TUPLE [NATURAL_32, INTEGER] (ANY,97,8):
    Colin> target class TUPLE [NATURAL_32, INTEGER] (267,25): argument
    Colin> class TUPLE [NATURAL_32, INTEGER] (54,40): assignment
    Colin> Attachment stack #3 class TUPLE [NATURAL_32, INTEGER]
    Colin> (ANY,97,8): target class TUPLE [NATURAL_32, INTEGER]
    Colin> (267,25): argument class TUPLE [NATURAL_32, INTEGER]
    Colin> (36,2): built-in Argument type: 'NATURAL_32' Attachment
    Colin> stack #1 class TUPLE [NATURAL_32, INTEGER] (ANY,97,23):
    Colin> argument class TUPLE [NATURAL_32, INTEGER] (267,35):
    Colin> argument class TUPLE [NATURAL_32, INTEGER] (56,39):
    Colin> assignment class TUPLE [NATURAL_32, INTEGER] (60,2):
    Colin> built-in Attachment stack #2 class TUPLE [NATURAL_32,
    Colin> INTEGER] (ANY,97,23): argument class TUPLE [NATURAL_32,
    Colin> INTEGER] (267,35): argument class TUPLE [NATURAL_32,
    Colin> INTEGER] (50,40): assignment Attachment stack #3 class
    Colin> TUPLE [NATURAL_32, INTEGER] (ANY,97,23): argument class
    Colin> TUPLE [NATURAL_32, INTEGER] (267,35): argument class TUPLE
    Colin> [NATURAL_32, INTEGER] (36,2): built-in

    Colin> This doesn't even point me at the class to look at, let
    Colin> alone a line number.

    Colin> I guess they will be calls to do_all_with_index where I
    Colin> have failed to change a local variable from DS_ARRAYED_LIST
    Colin> [INTEGER] to DS_ARRAYED_LIST [NATURAL_32], and therefore
    Colin> probably some usage of
    Colin> {ST_STRING}.do_forward/all_with_index, so I can probably
    Colin> track them (there are a lot of these) down by checking
    Colin> callers of this routine from EiffelStudio, but wouldn't it
    Colin> be possible to give the line in the source code where this
    Colin> occurs?  -- Colin Adams Preston Lancashire

-- 
Colin Adams
Preston Lancashire