we recently added that

ok 🙂 will check with the alpha version, I think I was on a little bit outdated version when I was checking it. thanks 🙂

I noticed that throwing

CompilationErrorException

no longer fails the compilation task in Ksp anymore in the 1.4.30 alpha. Is that expected? I don't see how we can test for failure cases anymore since it operates seemingly only by logging (whereas I would expect it to fail a build)

or would it still fail the gradle task but not necessarily the compilation that triggered the errors?

Basically - I would expect the

KotlinCompilation

this is attached to fail, but it reports it was successful

Sounds like there is no actual compile failures due to the failed ksp task, i.e. failed ksp processing didn’t cause any miss on the necessary files for compilation? I don’t think we did this on purpose tho.

this is what I was doing before to fail the build https://github.com/ZacSweers/MoshiX/blob/main/moshi-ksp/moshi-ksp/src/main/kotlin/dev/zacsweers/moshix/ksp/JsonClassSymbolProcessor.kt#L179-L191

I thought KSP would eventually fail the compilation if anything was reported to the error logger, but seems that's not the case either 🤔

it does fail the build

1 sec i think we do have a test for that

hmm, I guess it just fails the Ksp task but not the underlying kotlincompilation?

hmm let me check how this works in room testing

yea we might've asbtracted in room to accept error diagnostics as failure: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:room/com[…]piler/processing/util/runner/KspCompilationTestRunner.kt;l=79

🤷

ahh gotcha

hmm

https://github.com/google/ksp/issues/122 is marked as closed but I think it's still needed. Reaching into diagnostics like room does seems brittle. Seems like failing early could also help avoid cases like dagger needing to increase max error counts if it tries to continue a bad build

I'd be fine with just letting processors throw on their own if they want, but I'm surprised to see that throwing an exception can result in a "successful" compilation

yea that makes sense i guess

that just didn't come up in room since we also prevent additional rounds if there is an existing error: https://cs.android.com/androidx/platform/frameworks/support/+/androidx-main:room/com[…]/androidx/room/compiler/processing/SyntheticProcessor.kt;l=73

I mean multiple rounds with multiple processors

if you mix dagger and autovalue in a codebase and one falls over..., good luck have fun 😂

if an error was logged in a round on one processor, at the end of the round, all processors will call

onError()

for error handling, that should help by overriding

onError()

I think we need to figure how to make the KotlinCompile task fail. I am not sure if this is 1.4.30 related issues or preexisting issues though

Might be 1.4.30. that exception is a special type of exception that kotlinc looks for, anything else will result in an "internal error" exit code

Kapt uses the same type to communicate failures

I see, I’ll take a look on that

Seems like that it only happens with

CompilationErrorException

, which is caught and treated specially by compiler.

KSPLogger.error("msg")

and

throw Error("msg")

do fail

kspKotlin

and blocks `compileKotlin`(which depends on

kspKotlin

)