And separate question. Is the expected behavior fo...
# ksp
e
And separate question. Is the expected behavior for the predicate passed to KSValidateVisitor to be returning true means to check the node and false means to skip assuming it's valid? Seeing some inconsistent behavior in it's implementation and wondering if it's a bug.
j
Not really assuming valid, but just not care about it. Like you might not care about a function’s parameter type if your annotation processor only need the return type information. What is the inconsistent behavior you are observing?
e
There's 2 issues I've found:
Copy code
visitFunctionDeclaration
will return false if the predicate returns false, so
validate()
will always say it's invalid if you choose to skip it
Copy code
visitPropertyDeclaration
checks
property.type.resolve().isError
instead of visiting, which means
property.validate()
may return true while
property.type.validate()
may return false. Seems inconsistent with other places in the visitor.
Here's my custom subclass, I can send a pr when I got time
Copy code
class FixedKSValidateVisitor(private val predicate: (KSNode?, KSNode) -> Boolean) : KSValidateVisitor(predicate) {
    override fun visitFunctionDeclaration(function: KSFunctionDeclaration, data: KSNode?): Boolean {
        if (!predicate(function, function.returnType!!)) {
            return true
        }
        return super.visitFunctionDeclaration(function, data)
    }

    override fun visitPropertyDeclaration(property: KSPropertyDeclaration, data: KSNode?): Boolean {
        if (predicate(property, property.type) && property.type.accept(this, data)) {
            return false
        }
        if (!this.visitDeclaration(property, data)) {
            return false
        }
        return true
    }
}
j
got your point, seems something should be fixed to me. But your custom class needs some tweak before merged, like in your class when the
predicate
indicates no check for function return type, it will return
true
directly while there are other places for validation like parameter types.
e
yeah that makes sense