Make more annotations extend ConstantAnnotation

[BalmungSan]

This makes it clearer that any custom error messages (e.g. on implicitNotFound) must be literal values.

Fixes scala/bug#10424

[lrytz]

I rebased this on top of #9379 and changed both implicitNotFound and implicitAmbiguous to extend ConstantAnnotation.

There are a bunch of workarounds required to get this green because the STARR compiler (2.13.4) doesn't yet have the fixes from #9379 and some additional compiler fixes from this PR (extract the implicitNotFound message from AnnotationInfo.assocs instead of AnnotationInfo.args - the data moves when starting to use ConstantAnnotation). User-code will not need such workarounds, the only change for users will be that the compiler enforces the implicitNotFound / implicitAmbiguous messages to be compile-time constants.

To avoid the internal workarounds, we can first merge only the compiler changes but keep implicitNotFound / implicitAmbiguous as-is until 2.13.5 is out. For me, either way is fine.

There are additional annotations that we should change to extend ConstantAnnotation: @deprecated, @deprecatedName, @deprecatedInheritance, @deprecatedOverriding, @elidable, @migration. Doing that before a restarr might require more temporary workarounds.

summon[@SethTisue.type]

[dwijnand]

Needs a rebase to not conflict. #9379 is now merged.

[dwijnand]

LGTM

Nvm, just realised this is based on a previous version of #9379. Needs a review after rebase.

[SethTisue]

@BalmungSan #9379 is merged now. Could you rebase this and remove all in the insertions of msg =, which iiuc shouldn't be necessary anymore?

also the PR title and description need revision now that the scope of the PR has broadened

[BalmungSan]

@SethTisue let me know if I rebased it correctly, or if I screw it up (I have a backup just in case).

About the title, I think it is fine, at the end of the day this PR is just enforcing the use of a literal value for the annotation message and improving the documentation to reflect that.

BTW, should I add the same documentation message to implicitAmbiguous?
Also, I am not sure if I should have also removed the changes from this commit?

---

Judging from the failed CI, I did screw it up.

[SethTisue]

@BalmungSan It seems the story got a bit more tangled than any of us expected. Your original goal here was simply to improve the implicitNotFound documentation, but that ended up leading us into deeper waters. I see now that I did not read Lukas's early remarks closely enough until now. You didn't screw up, it's me who suggested you take an approach that wouldn't work, or rather, won't work yet.

Let's proceed as follows:

1. I am closing this PR. Soon, I and/or Lukas will submit a different PR that includes only the Lukas's compiler changes that will make changing the annotations later possible.
2. After 2.13.5 is released and we re-STARR, I will submit a second PR reopen this PR and include the rest of the changes, including changing the other annotations Lukas suggests. I will keep your commit with your authorship.

[SethTisue]

@lrytz And before I can do that, I have a question. You wrote:

There are a bunch of workarounds required to get this green because the STARR compiler (2.13.4) doesn't yet have the fixes from #9379 and some additional compiler fixes from this PR (extract the implicitNotFound message from AnnotationInfo.assocs instead of AnnotationInfo.args - the data moves when starting to use ConstantAnnotation). User-code will not need such workarounds, the only change for users will be that the compiler enforces the implicitNotFound / implicitAmbiguous messages to be compile-time constants.

If I understand correctly, that means that some of the changes to AnnotationInfos.scala in this PR should be made now for 2.13.5, and some others are "workarounds" that won't be needed now that we're doing this in stages. Can you help me distinguish which is which? (Or perhaps it would be easier for you to just submit the 2.13.5 PR yourself than to verbally characterize it to me; I don't know.)

[lrytz]

Yes, that's right. I'll split up the PR so we can do the changes after the next restarr.

[lrytz]

#9463

[SethTisue]

I was unable to change @deprecatedName, since it has auxiliary constructors. Those constructors are deprecated, so we'll be able to make the change for Scala 3.x. I'll add a comment about it.

(Or, we could just remove the auxiliary constructors now, on the grounds that bincompat doesn't matter here since it's compile-time stuff? I've chosen to play it safe, but I don't have a strong opinion about it.)

[lrytz]

This needs some MiMa excludes and a check file update.

I agree to leave @deprecatedName

[SethTisue]

welcome, new Scala contributor!

[SethTisue]

it came up in the community build that something like this no longer compiles:

  @deprecated(
    """|Empty parts are not allowed by the multipart spec, see: https://tools.ietf.org/html/rfc7578#section-4.2          
       |Moreover, it allows the creation of potentially incorrect multipart bodies                                       
       |""".stripMargin,
    "0.18.12"
  )

because using .stripMargin makes it not a constant. I guess this is acceptable though

[BalmungSan]

@SethTisue note that the annotation was ignored since it wasn't a constant anyways.

Thus I would say that a compilation error is good.

[lrytz]

Yes, getting this error is exactly the the goal of this PR