[meta] Adopt trigger_error() for deprecation messages where it is missing

Definitely a good way to go about this.

Making this a plan issue because this will require a series of steps starting with the coder rule child issue. Also major, because this is a big part of adopting a much smoother major version upgrade process.

https://github.com/klausi/coder/pull/26 contains a PR now.

What is an @deprecation notice? The @deprecated tag? Or the trigger_error() calls? Can you describe an example in the issue summary what should be changed into what?

Adding @trigger_error() will have to be a case-by-case basis in tandem with removing usage of deprecated code. Contemplate that, for instance, \Drupal::entityManager() is deprecated, but is used extensively by the entity system.

So:

• Add the bridge in #2488860: Bring phpunit bridge into drupal and use it for unit tests and simpletest to handle Deprecation after fixing the deprecated usages the CI runs show (like this: https://www.drupal.org/pift-ci-job/646796 )
• Find all the deprecations that have already been disused in core, and add @trigger_error() to those in one big patch.
• Add the rest of the @trigger_error() calls on a case-by-case basis, at the same time as removing usages.

This is basically the same pattern as the CS fixes.

@Mile23, so you think that adding @trigger_error() should be done once core usages are removed? I was debating whether there was some way to test conditionally as usages were removed, but that route might make more sense.

Well if you look at that CI run you'll see that adding the symfony phpunit bridge fails all tests that use the deprecated code. Here: https://www.drupal.org/pift-ci-job/646796

So 1) Fix the deprecations that allow the bridge to be added without failing, 2) Add the bridge, 3) Start adding @trigger_error() at the same time as you remove usages.

Using the bridge would be the way to test conditionally. If we have the bridge, we can use it to fail usages per triggered error. Sort of like the coding standards stuff.

Hasn't been much movement here - do we still think automated is the way to go or are we better to crowd-source this?
They make good novice tasks.

Just to amend #8: What we did was to add a list of 'allowed' deprecation errors which would be ignored, in order to manage the technical debt. #2870194: Ensure that process-isolated tests can use Symfony's PHPunit bridge to catch usages of deprecated code

We are removing individual messages from the ignore list in #2959269: [meta] Core should not trigger deprecated code except in tests and during updates so they are 'live' and will fail tests.

Estimating ~80 files that have @deprecated but not @trigger_error().

$ grep -lr @trigger_error core/ | wc -l
     267
$ grep -lr @deprecated core/ | wc -l
     344

There was ideaof creating deprecated module, so it could maintain a list of deprecated stuff

I see no reason to have a rule in coder module because it willbe a pain to update it on each new deprecation.

The main target is to allow contrib and custom code to scan for deprecated usage (like phpstorm can) but that scan depends on core version used so it doesnot fits in coder module

+1 on #14.

I think there are too many edge cases for how to ensure there's a @trigger_error() using coder. Like, for instance: #2234479: Deprecate hook_test_* hooks in simpletest is weird because we have a special deprecated hook invoker on the module handler.

Updating IS.

I started head on on #3033332: [META] Fix language and consistency of deprecation messages and annotations which is about fixing the existing text itself. Since this is about adding trigger_error(), let's make the distinction clear.

Reading the discussion and issue summary here, this looks entirely the same as #2856744: [META] Add trigger_error(..., E_USER_DEPRECATED) to deprecated code which is actually making some progress recently. Please reopen and update significantly if this is different in any way.