Generic entity api field handler should live in views module not in field module

+1, most def

This is blocking a critical...

nitpick, but:

+++ b/core/modules/entity_reference/entity_reference.views.inc
@@ -11,7 +11,7 @@
-  $data = field_views_field_default_views_data($field_storage);
+  $data = views_field_views_field_default_views_data($field_storage);

views_field_views_field... ;-)
Any way we could unrecurse the name a bit ?

[edit: also applies to views_field_views_field_label()]

+++ b/core/modules/views/views.views.inc
@@ -165,5 +169,480 @@ function views_views_data() {
+function _views_field_views_get_entity_type_storage(FieldStorageConfigInterface $field_storage) {
+  $result = FALSE;
+  $entity_manager = \Drupal::entityManager();
+  if ($entity_manager->hasDefinition($field_storage->getTargetEntityTypeId())) {
+    $storage = $entity_manager->getStorage($field_storage->getTargetEntityTypeId());
+    $result = $storage instanceof SqlContentEntityStorage ? $storage : FALSE;
+  }
+  return $result;
+}

Also minor, but I think the current API around Entity type handlers could now let us check "does the storage class extend SqlContentEntityStorage ?" without actually instantiating the storage object ?

+++ b/core/modules/views/views.views.inc
@@ -165,5 +169,480 @@ function views_views_data() {
+      $result = (array) $module_handler->invoke($field_storage->module, 'field_views_data', array($field_storage));
...
+/**
+ * Have a different filter handler for lists. This should allow to select values of the list.
+ */
+function list_field_views_data(FieldStorageConfigInterface $field_storage) {

Wow - this used to work back in the days where the "list" field types were provided by a list.module, but I don't think this is ever called in current HEAD ?

Should be options_field_views_data(), and live in options.module ?

@dawehner : fair enough, will open a separate issue for #7.

Last remaining nitpick : can we also simplify the name of views_field_views_field_label() ?
(see #6)

views_[...]_field_[...]_label() : yeah, mulling on that.

Meanwhile:

--- a/core/modules/views/views.views.inc
+++ b/core/modules/views/views.views.inc

+use Drupal\Core\Field\FieldConfigInterface;

+function views_field_views_field_label($entity_type, $field_name) {
+  ...
+  ... $field_definition instanceof FieldConfigInterface ...

That's the wrong FieldConfigInterface, this will also catch BaseFieldOverrides, which we don't want here.
It should be Drupal\field\FieldConfigInterface, that's what the current field_views_field_label() uses.
See #2399301: There should be only one FieldConfigInterface :-/

views_entity_field_label() - why not I guess.

RTBC when #16 is fixed :-)

;-)

1.  * @see field_views_data()
   

    * @see field_views_data_alter()
   

   field_views_field_default_views_data()
   

   all appear in views.api.php and need changing since these functions no longer exist. There are multiple instances...

2. function list_field_views_data(FieldStorageConfigInterface $field_storage) {
   

   Isn't this function name problematic because there is hook_field_views_data? This is a separate, already existing, issue just noticed whilst reviewing.

3. /**
    * Implements hook_hook_info().
    */
   function field_hook_info() {
     $hooks['field_views_data'] = array(
       'group' => 'views',
     );
     $hooks['field_views_data_alter'] = array(
       'group' => 'views',
     );
   
     return $hooks;
   }
   

   I think this needs to move the views module.

Stuff from #21 addressed. Looks good to me.

Committed and pushed to 8.0.x. Thanks!

Published change record.

While working on #2395763: Fields are not 'click sortable' in views, I realized that as part of the fix here, the relevant test from the field module (Drupal\field\Tests\Views\ApiDataTest) should probably have also been moved to the views module. Should that be a separate follow-up issue?

I added #2404265: Follow-up: ApiTestData should be in the views module.