[PP-1] Consistent use of leading \ for class names in *.api.php files

Patch applies cleanly and the changes work well.

+++ b/core/includes/update.inc
@@ -9,6 +9,8 @@
+use Drupal\Core\Language\Language;
+use Drupal\Core\Language\LanguageInterface;

This suggests that update_language_list() should just be removed. Instead of adding these use statements here - can we file a separate issue to remove this method - it is obviously not working. It'd error immediately. It was added without usage in #1754246: Languages should be configuration entities.

The rest of the patch is a mixture of different types of coding standards for example:

+++ b/core/lib/Drupal/Component/Gettext/PoHeader.php
@@ -188,7 +188,7 @@ public function __toString() {
-   * @throws Exception
+   * @throws \Exception

+++ b/core/lib/Drupal/Component/Gettext/PoItem.php
@@ -104,7 +104,7 @@ public function getSource() {
-   * @param string or array $source
+   * @param string|array $source

+++ b/core/lib/Drupal/Core/Archiver/ArchiveTar.php
@@ -632,7 +632,8 @@ public function extractModify($p_path, $p_remove_path, $p_preserve = false)
+     * @return string|null $v_result
+     *   A string with the file content or NULL.

@throws, @param and @return. These should be addressed by the coding standards project. One at a time and by enabling coding standards rules in phpcs.xml.dist so that we don't introduce regressions.

In order to fix core coding standards in a maintainable way, all our coding standards issues should be done on a per-rule basis across all of core, rather than fixing standards in individual modules or files. We should also separate fixes where we need to write new documentation from fixes where we need to correct existing standards. This all should be done as part of #2571965: [meta] Fix PHP coding standards in core, stage 1. A good place to start is the child issues of #2572645: [Meta] Fix 'Drupal.Commenting.FunctionComment' coding standard.

For background information on why we usually will not commit coding standards fixes that aren't scoped in that way, see the core issue scope guidelines, especially the note about coding standards cleanups. That document also includes numerous suggestions for scoping issues including documentation coding standards cleanups.

Contributing to the overall plan above will help ensure that your fixes for core's coding standards remain in core the long term.

@xjm pointed out that I closed this prematurely.

• We agreed that the fixes to *.api.php are good and could be in-scope for this issue if we change the issue summary that way.
• We need to ensure that issues already exist to implement coder rules (if missing) and apply to them to core to fix the coding standards related changes (@param, @throws, @return, @var)
• We need a separate issue filed about update_language_list()

+++ b/core/lib/Drupal/Core/DependencyInjection/ContainerBuilder.php
@@ -6,6 +6,7 @@
+use Symfony\Component\DependencyInjection\Exception\InactiveScopeException;

@@ -34,7 +35,7 @@ public function __construct(ParameterBagInterface $parameterBag = NULL) {
-   * @return InstantiatorInterface
+   * @return \Symfony\Component\DependencyInjection\LazyProxy\Instantiator\RealServiceInstantiator

This is another reason why doing this via coding standards is good. This file intentionally follows Synfony's coding standards where this @return is valid.

@vidhatanand thank you for reviewing this issue!

The automated testing infrastructure tells us whether the patch applies, so we do not need people to review that. It is also not sufficient criteria for the issue to be marked "Reviewed and Tested by the Community".

What we do need people to review is whether the issue has a correct scope, whether it passes the core gates, whether the solution completely fixes the problem without introducing other problems, and whether it's the best solution we can come up with. See the patch review guide for more information.

When you do post a review, be sure to describe what you reviewed and how. This helps other reviewers understand why you considered the issue RTBC (and is considered for issue credit).

Re rolled because last one failed to apply.

This seems like a lot of different types of cleanups. I think they're all probably decent changes. But we're about to have 8.4-alpha, so some might be allowed changes and some might not by the time this gets reviewed. See the list of allowed changes here: https://www.drupal.org/core/d8-allowed-changes#alpha

Check out the links from #8 and maybe split this up into different issues depending on whether you think they'd be allowed in alpha.

Patch 12 contained changes for 73 files and this reroll has changes for 43. Nice to know that many of these fixes has already happened.

The patch remains a mixture of fixing different coding standards and no tests are being run on it. #7 says this should be about the *.api.php files and I'll do a patch for that next.

forgot to upload the patch. This is the reroll mentioned above.

This patch is just the changes for *.api.php files plus the patch from #3089634: missing initial backslash on parameter interface typehints in entity.api.php.

Changing to NR to run tests.

There is 3089634#15 from xjm in #3089634: missing initial backslash on parameter interface typehints in entity.api.php that is worth duplicating here.

xjm pointed out that *.api.php are just documentation and asked if Drupal Code Builder somehow parse them to do the code generation?
I personally would want to ensure this was fixed at least in all *.api.php either way. A sniff has still not been created yet and other *.api.php are also wrong, including in hook signatures and the like.

If we could get clarity on what exactly the bug that's being caused is, that'd make it easier to make sure we're fixing that bug completely (here and/or elsewhere).

This issue now covers all *.api.php file.

Closed #3089634: missing initial backslash on parameter interface typehints in entity.api.php as a duplicate and added credit here.

#7.3 Add the follow made as a related issue #2860277: update_language_list() should be removed