Should we remove the "experimental" tag from type-solving?

[BraisGabin]

Right now a lot of our rules use type-solving and it is battle tested. It works! But we still say in the documentation that it is "experimental" but, to me, it is not experimental at all. It's one of the core features of detekt.

So I would like to remove the "experimental tag" from the type-solving, what do you think?

Context

appKODE/detekt-rules-compose#5 (comment) The compose rule set doesn't use type-solving because it's tagged as experimental and I think that's really bad.

To me, the only thing that have some "unpulished edges" is the gradle integration. But I think that all of us agree that we are not going to add any breaking change there even with the "experimental" tag.

[cortinico]

Agree that is not experimental anymore.

On this topic, I should update our wording & task naming to something like:

• detektLite -> i.e. the current execution of detekt without Type Resolution
• detektFull -> i.e. Running with type resolution.

The Lite/Full naming will make easier for users to understand what is going on.

[TWiStErRob]

@matejdro Aren't the "requested tasks" part of the configuration cache key? As far as I observed, when we ask for different tasks, the configuration cache is recalculated.

[matejdro]

The way I understand it, requested tasks are keys for the configuration caches, but properties are inputs.

So, in detektLite/detektMain scenario:

1. I run detekt without type solving (detektLite) - configuration cache for detektLite is computed and saved
2. I run detekt with type solving (detektMain) - configuration cache for detektMain is computed and saved
3. I run detekt without type solving (detektLite) again - configuration cache for detektLite is reused, we don't need to recompute the configuration

However, in custom property scenario:

1. I run detekt without type solving (detekt -PenableTypeSolving=false) - configuration cache for detekt is computed and saved
2. I run detekt with type solving (detekt -PenableTypeSolving=true) - input has changed, so configuration for task detekt needs to be re-computed
3. I run detekt without type solving (detekt -PenableTypeSolving=false) - input has changed, so configuration for task detekt needs to be re-computed

Re-running the task again (step 3) will only reuse configuration cache in detektLite/detektMain scenario

[TWiStErRob]

I see, thanks for the steps, it really helps understand what you meant and from the docs I also read it similarly. You bring a good point about this behavior being problematic. However, I don't think this would be every-day user behavior, right? What would be the use case for running with type resolution on/off in sequence? I would imagine that projects would choose to accept type resolution as the default, or override it to be off, but not toggle between them often. (Except maybe in the initial phase when build engineers are trying to see differences in output, but that's the .01% of the use, the rest is CI and devs running it as configured.)

I made a repro to confirm this behavior and play around a bit; I also opened a Gradle issue, because this looks strange. Properties invalidate the cache entries, but not used as part of the key. I'm curious why this is happening.

[matejdro]

Yeah, you are right, that this is an edge case. Just wanted to mention it in case there is a tie between the two options, as a minor point for the two tasks side.

[TWiStErRob]

I would like to note for maintainers that the internal implementation of the type resolution in DGP can be still be done with a flag, regardless of which user facing task pattern is chosen at the end:
https://github.com/TWiStErRob/repros/blob/main/detekt/typeResolution-configurationCacheFlag/build.gradle.kts