Specify type explicitly in KotlinCoreProjectEnvironment.createCoreFil…

[MarcinAman]

…eManager to allow overriding this method with different implementation

Right now the type is KotlinCliJavaFileManagerImpl which defeats the point of inheritance since no one is able to substitute the result with own implementation.

[udalov]

Hi! Thanks for the contribution. Could you please explain why you need this change?

[MarcinAman]

I don't strictly need it, it is more of a nice nice addition.
To give you some background story: In dokka we have a quite peculiar issue with trove hashing that i think comes from the compiler itself: Kotlin/dokka#1599

As far as i can tell it is related to multithreaded use of the analysis. For us specially KotlinCliJavaFileManagerImpl and JvmDependenciesIndexImpl classes are quite problematic since they sometimes fail the whole analysis. I've debugged this a little bit and it appears that trove is not suitable for multithreaded use and if it encounters a duplicate value during rehashing it simply throws an exception. Imho duplicates occur when multiple instances of object with same hashcode are added in 'the same time'.
So, as a way to mitigate this issue for now i'd like to add synchronised use for trove maps in those files and add them to dokka analysis. Right now we use:

fun createForProduction(
            parentDisposable: Disposable, configuration: CompilerConfiguration, configFiles: EnvironmentConfigFiles
        ): KotlinCoreEnvironment

To get environment but i thought that i'd just use:

fun createForProduction(
            projectEnvironment: JavaCoreProjectEnvironment, configuration: CompilerConfiguration, configFiles: EnvironmentConfigFiles
        ): KotlinCoreEnvironment

to get environment and pass it my class that inherits from KotlinCoreProjectEnvironment and overrides createCoreFileManager with my, synchronised, implementation.

This approach unfortunately fails because i am obligated to provide KotlinCliJavaFileManagerImpl in createCoreFileManager and it can be inherited.

Because of that i think that it is not the best approach to enforce the implementation in the return type.

As for the whole multithreaded trove issue: i will probably create a PR for that (at least for discussion) but i am not entirely sure how to unhack 1 thing there :D
Ofc for now we just shadowed yours classes on classpath with our synchronised versions but this is quite unfortunate solution as we just wanted to have a build.

[udalov]

Thanks!