Version

3.0.9

Reproduction link

https://vue-next-template-explorer.netlify.app/#%7B%22src%22%3A%22%3CFoo%3E%5Cn%20%20%3Ctemplate%20v-for%3D%5C%22i%20in%203%5C%22%20%2F%3E%5Cn%20%20%3Ctemplate%20v-for%3D%5C%22i%20in%203%5C%22%20v-slot%20%2F%3E%5Cn%3C%2FFoo%3E%22%2C%22options%22%3A%7B%22mode%22%3A%22module%22%2C%22filename%22%3A%22Foo.vue%22%2C%22prefixIdentifiers%22%3Afalse%2C%22optimizeImports%22%3Afalse%2C%22hoistStatic%22%3Afalse%2C%22cacheHandlers%22%3Afalse%2C%22scopeId%22%3Anull%2C%22inline%22%3Afalse%2C%22ssrCssVars%22%3A%22%7B%20color%20%7D%22%2C%22bindingMetadata%22%3A%7B%22TestComponent%22%3A%22setup-const%22%2C%22setupRef%22%3A%22setup-ref%22%2C%22setupConst%22%3A%22setup-const%22%2C%22setupLet%22%3A%22setup-let%22%2C%22setupMaybeRef%22%3A%22setup-maybe-ref%22%2C%22setupProp%22%3A%22props%22%2C%22vMySetupDir%22%3A%22setup-const%22%7D%7D%7D

Steps to reproduce

Check the console for the AST

What is expected?

AST tree is:

• ROOT
  • ELEMENT
    • FOR
    • FOR
      • ELEMENT(directives: slot)

What is actually happening?

AST tree is:

• ROOT
  • ELEMENT
    • FOR
    • ELEMENT(directives: for, slot)

Related: https://github.com/johnsoncodehk/volar/issues/110

This seems to be intentional. With or without v-slot determines whether it needs to be processed by the vFor transform, so in essence, they are treated differently. We can see the details here https://github.com/vuejs/vue-next/blob/master/packages/compiler-core/src/transform.ts#L463-L465

Can we change this implement if this is not the design?

This should be by design, we need @yyx990803 input.

<template v-for="..." v-slot> generates code like createSlots({ ... }) since it's dynamically generated slots. In this case the codegen tree is the source of truth and the original AST is left untouched. We can technically adjust the behavior, but it will solely be for external tooling and actually risks breaking existing compiler logic. I think it's better to keep the behavior and special case it in Volar.