Remove compiler warnings

[bcardiff]

There was a core team discussing where the consensus was to

• Keep @[Deprecated]
• Remove compiler checks on deprecated methods
• Add, at least initially, the deprecation checks as a separate compiler tool

This PR reverts #7626 and #7596, but keeps the compiler fixes found along the way.
It closes #7650 since that is embedded in the current implementation.

The deprecation check tool will probably come after 0.28

[j8r]

Why, what was the conclusion? Can't it be available behind a feature flag?

[straight-shoota]

@j8r While discussing the existing implementation we decided that we want to make it better and work on a different solution as a compiler tool. But we don't want to delay 0.28.0 to wait for this replacement.
Changing the existing implementation to an opt-in preview feature was considered, but since that code won't stick around anyway it makes more sense to remove it right away as it can't serve as a preview for a different tool anyway.

[j8r]

I guess having proper RFCs would help communication, and understand the design decisions... The community won't know what happens in a black box channel.

[bcardiff]

@j8r I've just created #7655 for that. The original PR served as discussion, it had substantial changes from the opening to the final approval and merge, but there were some more opinions to come. At the end of the day, the story is still moving forward.

[straight-shoota]

I think we should also drop the strict validation of Deprecated annotation arguments from the compiler. Let's allow having yet-unspecified named arguments. This enables us to discuss adding additional arguments and already use them in code without breaking it for a 0.28.0 compiler.

We don't really gain anything from the strict validation, especially since it's only implemented on methods anyway.

[bcardiff]

@straight-shoota if there are no restrictions, then is hard to give semantics.

[straight-shoota]

This is okay to merge in any case 👍

[Sija]

@straight-shoota I'd wait for resolution of the issue #7655, since this approach raised a lot of valid questions, which IMO should be tackled before any merge happens.

[straight-shoota]

@Sija The decision was not to delay 0.28 for #7655. There is no hurry for this feature. Let's take some time and make it a great one. The discussion can continue without any rush for meeting the milestone.

[asterite]

@straight-shoota What if we let the warnings be integrated in the compiler, but opt-in for 0.28.0? Then people can try them out and if they turn out to be very useful we can make them opt-out for 0.29.0. Or even the other way around: opt-out for 0.28.0, and if they turn out to be very annoying we can make them opt-in for 0.29.0 or even 0.28.1.

I'd really like to try it opt-out first. If we don't try and experiment with new things we'll never know what's the real reaction or usefulness of this. And, as I said somewhere else, you can always pass a flag to silence the warnings.

[straight-shoota]

I was personally okay with having it as opt-in. But the consensus was to drop this compiler feature for 0.28.0 entirely. I'd strongly recommend we stick to this decision instead of burning our fuel on discussions about whether we should diverge. Let's focus our attention on releasing 0.28.0 and designing the deprecation warnings feature in #7655.

Shipping this as an opt-out feature as currently in master is a no-go from @RX14 and me. Reports for every invocation has the potential of spamming the console output with pages of deprecation messages. We should be really sure about how it behaves on a larger scale before shipping such an annoying release.

[asterite]

@straight-shoota No, that was what you and @RX14 wanted, but me, @bcardiff and @ysbaddaden want it as opt-out. That's not consensus.

[j8r]

I think including it as opt-in is a good compromise between complete removal and enabling it by default with opt-out.
It's close to the feature flag, but with more exposure, being documented in the CLI.

[Sija]

I have no insight into your decision process guys, but I definitely agree with @asterite on that, only if everyone are on board with the decisions at hand you can call it a consensus, not before.

[straight-shoota]

Well, not not everyone was present in the discussion. It was an adhoc meeting and it became apparent that we needed a decision on what to do about the upcoming release. After an intensive discussion of 2 hours or so we agreed on the course of action. Which was then presented in this PR and the dicsussion about the content continued in #7655. And I think the result should be okay for everyone - and so is probably #7661. Neither is preferred by everyone, but both should be acceptable.