Fix pallet error spam when there is really just one simple error

[sam0x17]

Created from this comment #264

Currently, if your pallet has a syntax error, you get an error for it, and then a gzillion other errors because the corrupt/incomplete pallet code is still being treated as Rust code. Ideally, we'd tell the compiler to stop immediately.

This is largely due to missing trait impls or structs during pallet expansion resulting from some error that prevented some part of the expansion from running. There are a lot of situations where this can happen, so the surface area for fixing this issue could be rather large, however the approach should be to proactively detect that something is missing and issue a compile error there, before pallet expansion begins.

Generally speaking, we want to make sure that the "validation" phase of all of our pallet macros happens during parsing, and that avoid issuing errors during expansion

[bkchr]

I also thought about this already multiple times. If we introduce some validation phase, which we generally already have as the parsing phase or whatever we do, we should always expand. Maybe if we detect issues we expand with some "best effort". Otherwise we would still see a lot of unrelated errors.

But yeah, in general that is probably something that requires some tinkering to find the best way to handle certain errors.

[sam0x17]

Yeah, I think the key is to catch these types of errors and issue a compiler error with an appropriate span before any expansion has started, but will have to try it to know for sure

Doing "best effort" stuff might actually be causing this in some cases where because something is missing beacuse something else failed, we get 100 errors

[bkchr]

I don't think that we currently generate types on best effort. Afaik we bubble up the error to the top and then don't generate anything.

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/ink-analyzer-300-unique-vs-code-extension-installs-preparing-for-ink-v5-moving-to-retroactive-treasury-funding-and-gauging-interest-in-a-frame-equivalent/6512/2

[Polkadot-Forum]

This issue has been mentioned on Polkadot Forum. There might be relevant details there:

https://forum.polkadot.network/t/ink-analyzer-300-unique-vs-code-extension-installs-preparing-for-ink-v5-moving-to-retroactive-treasury-funding-and-gauging-interest-in-a-frame-equivalent/6512/3