eolian: get rid of false positives about unimplemented methods

Authored by q66 on Jan 23 2019, 8:59 AM.


eolian: get rid of false positives about unimplemented methods

We worked under the assumption that when inheriting callables
from a regular class, it's good enough to just set those as
fully implemented, because the underlying class is already
checked. This assumption is wrong, as the callables may contain
multiple implements pointing at the same function (consider when
a regular class implements just the get part of a property but
some underlying class implements it whole) - the old logic would
result in just the first reached implement (possibly incomplete)
being added into callables of the inheriting class, which results
in false positives.

Consider this example:

class A has a fully implemented property foo
class B inherits from A and partially implements foo
abstract C inherits from B
class D inherits from C

abstract C would go over B's implements, encounter the first
partial implementation of foo, adding it into its own callables
and marking it as fully implemented (because it came from an
already checked regular class B), which would result in the
other implement being skipped.

So make no assumptions and use the same logic for all class types.

Of course, this brings in another problem: some errors would now
get printed twice, because if you have a class A which has funcs
that are unimplemented and class B inheriting from it, errors would
get printed for A but also for B, which would include A's errors.

To battle that, introduce a "global" (well, local to the entry
point of the validator) hash tracking which implements have already
been errored on; and skip those appropriately.


q66Jan 23 2019, 9:08 AM
rEFL09a83d216163: efl_ui_win: move base and step size hints here