Feature request: allow specifying suppressions for generated files

[ZacSweers]

We enable warnings as errors in our project, which sometimes means suppressing a deprecated usage in a type but this isn't carried over to the generated code. It would be neat if we could disable these via specifying suppressions we need

anvil {
  suppressions = setOf("DEPRECATION")
}

// results in files including
@file:Suppress("DEPRECATION")

[vRallev]

To be crystal clear I assume this would be a sample:

@Deprecated("abc")
class MyType

@Module
class MyModule {
  @Provides fun provideMyType(): MyType = MyType()
}

Which results in this error:

e: warnings found and -Werror specified
w: anvil/integration-tests/library/build/anvil/src-gen-main/com/squareup/anvil/test/MyModule_ProvideMyTypeFactory.kt: (11, 13): 'MyType' is deprecated. abc
w: anvil/integration-tests/library/build/anvil/src-gen-main/com/squareup/anvil/test/MyModule_ProvideMyTypeFactory.kt: (12, 32): 'MyType' is deprecated. abc
w: anvil/integration-tests/library/build/anvil/src-gen-main/com/squareup/anvil/test/MyModule_ProvideMyTypeFactory.kt: (20, 49): 'MyType' is deprecated. abc
w: anvil/integration-tests/library/src/main/java/com/squareup/anvil/test/Modules.kt: (40, 41): 'MyType' is deprecated. abc
anvil/integration-tests/library/src/main/java/com/squareup/anvil/test/Modules.kt: (40, 50): 'MyType' is deprecated. abc

[ZacSweers]

Yup!

[ZacSweers]

I see you went with the hardcoded approach. Any reason not to use a generic option like I mentioned above? Another one that comes up occasionally is explicit API mode from kotlinpoet leading to redundant qualifiers, which would be a different suppression and not covered by the hardcoded deprecation warning.

[vRallev]

We talked somewhere else about this. So far there's no need for such an API and the hardcoded approach works good enough.