Incorrect API example about default widget override

Thanks for the patch.

1) Patch applies cleanly to 8.9, 9.0, and 9.1.

[mac:kristen:drupal-8.9.x-dev]$ patch -p1 < wrong-api-example-about-default-widget-override-3113124-1.patch 
patching file core/modules/field/field.api.php

[mac:kristen:drupal-9.0.x-dev]$ patch -p1 < wrong-api-example-about-default-widget-override-3113124-1.patch 
patching file core/modules/field/field.api.php

[mac:kristen:drupal-9.1.x-dev]$ cd91
[mac:kristen:drupal-9.1.x-dev]$ patch -p1 < wrong-api-example-about-default-widget-override-3113124-1.patch 

2) Searching the code before the patch for "default widget" and only found the item from the patch (other than in comments):

./core/modules/field/field.api.php:    $info['foo']['default widget'] = 'mymodule_widget';

3) After patch, default widget is changed to default_widget as expected.

4) Marking RTBC though not sure this needs manual testing.

Thanks, good catch. It is indeed default_widget, as can be seen in the code that responds to it in \Drupal\Core\Field\WidgetPluginManager:

    // Switch back to default widget if either:                                 
    // - the configuration does not specify a widget class                      
    // - the field type is not allowed for the widget                           
    // - the widget is not applicable to the field definition.                  
    $definition = $this->getDefinition($configuration['type'], FALSE);
    if (!isset($definition['class']) || !in_array($field_type, $definition['field_types']) || !$definition['class']::isApplicable($field_definition)) {
      // Grab the default widget for the field type.                            
      $field_type_definition = $this->fieldTypeManager->getDefinition($field_type);
      if (empty($field_type_definition['default_widget'])) {
        return NULL;
      }
      $plugin_id = $field_type_definition['default_widget'];
    }

(Or, for that matter, in the annotation of every field type plugin... I don't know that spaces are even possible in annotation keys since the annotation definitions are mapped onto variables in each annotation class.)

Committed to 9.1.x and cherry-picked to 9.0.x, 8.9.x, and 8.8.x as a patch-eligible documentation bugfix. Thanks!