Localized view macro errors + Prop autocomplete

[lpotthast]

Fixes #4628
Fixes #4630

Hey @gbj,

in this branch, I tried to make errors be reported where they actually happen, so that they do not disturb a user, but instead steer them in the right direction for quickly fixing them. No error should ever span the entire view! macro. Custom messages should be emitted where possible. When multiple things are erroneous, no error should be hidden until an earlier error is resolved. The changes should be as non-breaking as possible.

(Though this could be done with a few quick "replace quote! with quote_spanned!" and a few span re-calculations here and there... But oh boy, was I wrong. I do think there could have been a smaller/more focused change that might accomplish the same, but I had to refactor some parts to make sense of it. Sorry for the inconveniences of such large changesets! :/)

Please see leptos_macro/LOCALIZED_ERRORS.md for an overview of what changed and how.

As a summary:

• Both components and slots now generate a companion module that can be used to store an arbitrary amount of additional type-machinery
• Props no longer take the full generics, following the late-bound approach also followed in most other leptos areas
• A new helper struct is used to track presence of required props and to validate each props type
• As a result:
• view! errors are now properly scoped
• Custom on_unimplemented messages provide nicer feedback for users
• A new suite of trybuild tests can catch regressions in error locality
• Prop autocompletion now works! (totally by accident ^^, was kinda surprised when I discovered this)

These macro code-gen changes add purely compile-time validation. Sadly, this comes at a slight cost of around 6.5% WASM binary size increase in debug builds. In release builds, there is no difference with main/latest on crates.io, as all new code is indeed optimized away. I don't have any more ideas on how the impact on debug builds could be reduced. But I also do think that this is an acceptable price for the gain in developer experience.

Examples:

Missing required prop:

Component requires children:

Wrong concrete prop type:

Wrong generic prop type:

Wrong children:

Autocomplete:

[gbj]

Wow!

Well, the results in the screenshots certainly look great, along with the other results you've reported.

Sadly, this comes at a slight cost of around 6.5% WASM binary size increase in debug builds.

Debug build WASM size is not an issue at all. Release build WASM size would be a concern if it was affected. It sounds like you're saying it is not?

Compile time in larger codebases is the other question that matters.

Sorry for the inconveniences of such large changesets!

No worries -- sometimes it takes what it takes to get something done. I hope you'll understand it may take me a while to find time to review.

Thanks so much, this looks like it could be a big improvement.

For anyone else reading: I'd really appreciate help reviewing some of this. The next six weeks or so is the time of year when I have the least time, so any help would be welcome.