fix #10247: skip deprecation warnings in synthetic definitions

[bishabosha]

fixes #10247

In this change we avoid all deprecation warnings when directly within a synthetic definition.

perhaps this is too permissive? i.e. Is there a place desirable for a synthetic def to warn about calling a deprecated member?

e.g. in this example in issue #10247 the enum case Red is deprecated, but is used to define both the values array and the valueOf lookup method, but these should not cause warnings

[smarter]

perhaps this is too permissive? i.e. Is there a place desirable for a synthetic def to warn about calling a deprecated member?

Yes, user code can be moved inside a synthetic definition (for example, the body of an anonymous class, the body of a lambda, etc). How does Scala 2 deal with this problem?

[bishabosha]

scala 2 does the same:
https://github.com/scala/scala/blob/01fba6681110b1afddd2aeb8b009ee83c67e6aad/src/compiler/scala/tools/nsc/typechecker/RefChecks.scala#L1279

with configurable warnings ported you could suppress deprecation warnings with a @nowarn annotation on $values and valueOf. Otherwise this problem would need a special case to scan for methods looking like those and defined in the companion of an enum

[smarter]

Is it the same? I see that it skips deprecated warning inside deprecated definition but I don't see anything about synthetic.

[bishabosha]

Is it the same? I see that it skips deprecated warning inside deprecated definition but I don't see anything about synthetic.

sorry I meant the same as status quo in Dotty

[bishabosha]

Final alternative could scan for @nowarn annotation with no argument, as that is the default behaviour in scala 2. Which that special case should then be removed when the full configurable warnings feature is ported

[smarter]

If we can't find other problematic cases than enums then I would just special case that: a deprecated enum case used anywhere inside the enum { ... } block where it's defined should not lead to warnings (so the user can use it in defs inside the enum too).

[bishabosha]

If we can't find other problematic cases than enums then I would just special case that: a deprecated enum case used anywhere inside the enum { ... } block where it's defined should not lead to warnings (so the user can use it in defs inside the enum too).

^ This would be fine with me.

for the sake of a counter argument Scala 2 would complain about using a deprecated definition in the same scope it is declared:

sealed trait Color
object Color {
  @deprecated("stop using Red") case object Red extends Color
  case object Green extends Color
  case object Blue extends Color
  def values = Array(Red, Green, Blue)
//                   ^
//  6: warning: object Red in object Color is deprecated: stop using Red
}

Overall, I agree it would be consistent to apply the rule across a whole enum declaration. This would allow for layering on top a model for enums that can deprecate cases

[bishabosha]

will reopen a new pr with the different changes