Remove theme_views_form_views_form in favour of a prerender callback.

Looks good. Only two small nitpicks:

+++ b/core/modules/views/templates/views-form-views-form.html.twig
@@ -0,0 +1,16 @@
+* Drupal code sprint convert templates to twig

Remove this line.

+++ b/core/modules/views/views.theme.inc
@@ -1005,9 +1005,17 @@ function template_preprocess_views_exposed_form(&$vars) {
+function template_preprocess_views_form_views_form(&$variables)
+{

No newline here, just ) { . See Drupal coding standards.

Applied changes from above feedback ...

I have a sneaky suspicion that this doesn't need to be in the theme layer at all.

+++ b/core/modules/views/templates/views-form-views-form.html.twig
@@ -0,0 +1,15 @@
+* @see template_preprocess()
+* @see template_preprocess_views-form-views-form()

nitpik: should be underscores.

Though I don't think the fails are your fault at all: tpl.php is getting appended to the end.
views/templates/views-form-views-form.html.twig.tpl.php

theme_views_form_views_form() could possibly be moved to a #pre_render callback

The tests are all failing because it is searching for:

views-form-views-form.html.twig.tpl.php

and the file in the patch is named:

views-form-views-form.html.twig

Which is intended to be correct under the new architecture? I do not know ...

In #drupal-twig:

I have a feeling "theme_views_form_views_form()" doesn't need to be a twig conversion nor a theme function, what do you think?

I admit I am not very familiar with drupal. This twig conversion just renders the output from the drupal core function related to form rendering:
drupal_render_children()

So the question in my mind is - what is the relationship between twig and the drupal form api?

This should have the changes to make it fly, but I am going to do another one for #pre_render callback as suggested by tim in #8

So this probably will pass, but I don't think it's right... I couldn't find a test for substitutions. but this is an attempt at #8

Ok using real variables this time:)

Tagging.

Yes, the theme function is not needed, but i'm wondering whether people actually want to have a theme function, so they can adapt if needed, which is much harder if you just have a form + preprocess function.

doing some manual testing.

Actually, I'm not 100% sure what the manual testing steps are here. Could somebody with a bit more experience with this issue help me out here?

Is this for a "front end" form like an exposed filter?

I agree with @thedavidmeister as it is not clear were to test this visually.

@dawehner in #16: I guess we should make it as easy as possible for themers. But then again where is this patch visible.

Can't be reviewed until we know where the template is.

Enable the actions module and import the following yml file into your drupal installation. This will provide you a view with a bulk operations form.

great! thanks @dawehner.

Imported view from dawehner #21 and did daisydiff on clean/patched. Manual testing did not gave any issues.

Great, on to profiling!

I have no idea what to test for. I opened a form and everything was normal. Can someone post a more detailed description of the modification?

Both the admin/content and admin/people view are now views forms. Try using them (unpublish nodes, block users).

I tested by adding and changing published content to unpublished content. I did a similar thing for an admin. It works well. Good work.

Updated issue summary.

Thanks for testing @adamcowboy, this still needs profiling before we can RTBC it though.

This needs a reroll before it can be profiled.

Rerolled and retitled as this no longer is a Twig conversion.

#30: 1912600-30-twig-views-form-views-form.patch queued for re-testing.

#30: 1912600-30-twig-views-form-views-form.patch queued for re-testing.

I guess we also need some manual testing?

@dawehner there was some manual testing but it wouldn't hurt to do another round. Is there any chance you know of a good way to test this? Most of what it does is for "substitutions" which I am not really sure what they are...

You are totally right! Here is a final nitpick.

@@ -1303,6 +1304,43 @@ function views_form_views_form_submit($form, &$form_state) {
+ * @return array
+ *   The $element with prepared variables ready for #theme 'form' in views_form_views_form.

This comment line is > 80 chars.

Oh the shame! :P

Does this need profiling? Anybody know of a view with lots of 'substitutions'? or any for that matter...

The same code is executed and just moved ... so I don't see really a need for profiling.

Awesome clean up!

Committed and pushed to 8.x. Thanks!