Why did I think Travis would let me "tweak" the spec? What hubris!

When the brain fog lifts, I'd like to take a moment to review whether expanding deprecation exemption via companion is a good idea. It came up on dotty for the same reason. Trying to minimize future reversions for @lrytz .

What PR does this revert?

It's crossed out in the first comment.

This doesn't revert the direct fix, but the expanded immunity to deprecation.

Shouldn't the deprecation be copied over to the companion?

diff --git a/src/library/scala/deprecated.scala b/src/library/scala/deprecated.scala
index 1459cd8192..25b7b54619 100644
--- a/src/library/scala/deprecated.scala
+++ b/src/library/scala/deprecated.scala
@@ -56,6 +56,6 @@ import scala.annotation.meta._
  *  @see    [[scala.deprecatedOverriding]]
  *  @see    [[scala.deprecatedName]]
  */
-@getter @setter @beanGetter @beanSetter @field
+@getter @setter @beanGetter @beanSetter @field @companionObject
 @deprecatedInheritance("Scheduled for being final in the future", "2.13.0")
 class deprecated(message: String = "", since: String = "") extends scala.annotation.ConstantAnnotation

(except that @companionObject doesn't seem to be implemented)

@lrytz deprecating the companion is the previous/old behavior objected to on the related dotty ticket.

(test neg/t2799.scala)

OK, thanks. scala/scala3#12706 (comment)

I was thinking to deprecate synthetic companions derived from deprecated classes, but then that doesn't work if the companion exists in source.

Also, deprecating the module class (95d7ef40eb) instead of the module symbol was probably unintended magic :)

This did not revert the code comment. I need tooling that detects nearby code comments and verifies whether I intended to update the comments.