Fix #7404: skip v-model & value binding collision check with dynamic type binding

[Justineo]

What kind of change does this PR introduce? (check at least one)

• Bugfix
• Feature
• Code style update
• Refactor
• Build-related changes
• Other, please describe:

Does this PR introduce a breaking change? (check one)

• Yes
• No

If yes, please describe the impact and migration path for existing applications:

The PR fulfills these requirements:

None.

• It's submitted to the dev branch for v2.x (or to a previous version branch), not the master branch
• When resolving a specific issue, it's referenced in the PR's title (e.g. fix #xxx[,#xxx], where "xxx" is the issue number)
• All tests are passing: https://github.com/vuejs/vue/blob/dev/.github/CONTRIBUTING.md#development-setup
• New/updated tests are included

If adding a new feature, the PR's description includes:

• A convincing reason for adding this feature (to avoid wasting your time, it's best to open a suggestion issue first and wait for approval before working on it)

Other information:

None.

[HerringtonDarkholme]

I wonder how generated code handle duplicate properties for code like <input :type="type" :value="v" v-model="m">.

Generated code will have a conditional branch for type = "text", in that branch, I wonder if Vue will generate domProps: { value: ..., value: ...}. As the original warning is to avoid duplicate properties error in IE11, lifting the constraint alone will make the error regress.

[Justineo]

Generated code will have a conditional branch for type = "text"

Yes I'm aware of this. It may become this question: are we gonna emit a warning message for something might cause error but in we cannot be sure about that during the compiling stage? When the user handles the data correctly, it will work as expected. Or in this case, at least we should warn that v-model and :value will conflict for some input types so users should be careful about the actual type they provide.

[HerringtonDarkholme]

are we gonna emit a warning ... during the compiling stage?

In this case it might be too noisy for legitimate use. Warning after this pull request is good enough IMHO. However, a patch is still needed to handle code generation, like suppress :value emission when both type is dynamic and v-model is set.

If warning is really desirable, generating a runtime warning in type="text" branch is more pleasant in terms of DX. But it should be fine without it.