Deprecate XML literals

[SethTisue]

@nicolasstucki seems like probably an oversight that there isn't already a ticket on this? (that I can find)

not sure what the right timetable is. at present, it doesn't even warn under -source:future

% scala-cli -S 3.nightly -source:future --dep org.scala-lang.modules::scala-xml:2.2.0
Welcome to Scala 3.4.0-RC1-bin-20231127-41e7d95-NIGHTLY-git-41e7d95 (17.0.9, Java OpenJDK 64-Bit Server VM).
Type in expressions for evaluation. Or try :help.
                                                                                                    
scala> <foo/>
val res0: scala.xml.Elem = <foo/>

at minimum, I think it should warn under -source:future, as the SIP committee has already authorized the eventual removal of XML literals from the language, and the Scala 3 reference doc already lists it under "Dropped Features" (https://docs.scala-lang.org/scala3/reference/dropped-features/xml.html)

whether it's time to actually deprecate, I don't have a strong opinion about. I don't know how polished or usable https://github.com/lampepfl/xml-interpolator is. the availability of a suitable substitute has always been the major concern here, iirc

[SethTisue]

Also, I think the XML chapter of the Scala 3 spec could be deleted. I don't think we need to wait for the feature to actually be deleted from the compiler. It's already legacy, and it will remain available in the Scala 2 spec for reference. cc @sjrd

[SethTisue]

with #19101 merged, the default behavior remains not-even-a-warning, but the -source:future behavior is a hard error:

1 |<foo/>
  | ^^^^^
  |XML literals are no longer supported.
  |See https://docs.scala-lang.org/scala3/reference/dropped-features/xml.html

[nicolasstucki]

This behavior was intentional. We decided to deprecate it later. See https://github.com/orgs/lampepfl/projects/2/views/11

[SethTisue]

Someone could check and see if the error is downgradeable to a warning, or silenceable entirely, using the -Wconf/@nowarn mechanism. I would expect that to work – as a general matter, errors should only be truly hard if the compiler is actually unable to proceed. cc @goshacodes

[goshacodes]

@SethTisue I've tried -Wconf and @nowarn and it is not configurable, always an error. I've thought about it, I guess there is no problem to make it a string and parse it for now

Someone could check and see if the error is downgradeable to a warning, or silenceable entirely, using the -Wconf/@nowarn mechanism. I would expect that to work – as a general matter, errors should only be truly hard if the compiler is actually unable to proceed. cc @goshacodes