Does it make sense to add a CI run where the use of std::vector triggers a compilation failure similar to what we have for unqualified move?

Does it make sense to add a CI run where the use of std::vector triggers a compilation failure similar to what we have for unqualified move?

That would be great, but I'm not sure how we would add something like this.
The std::move one is different because we made duckdb::move throw the static assert, this case is reverse.

We could add a script that scans files for the use of std::vector?

A couple changes made to safe_unique_ptr are also relevant here:

• Changes to exception.hpp, so we can inline the bounds check (probably needs more changes, because 'exception.hpp' heavily uses 'vector')
• clear() needs the same if (DUCKDB_CLANG_TIDY) -> clang::reinitializes treatment

Merged with #6967 - I suspect that will get merged first, so I figured I'd skip a need to merge later

The PR on the wasm side just got merged, that should be the final puzzle piece to get this PR passing CI 🤞
Not sure if the wasm version upgrade should have been a separate PR instead?

I think it makes sense to have the changes to duckdb-wasm hash here, since they are connected. Looks good.

Also worth writing down somewhere that currently duck-wasm hash is used only for testing changes in duckdb, and no one is relying on generated build artifacts, so there are no visible consequences, only ducdkb developers will see potentially different test results (but that's true with any PR...).

This is to say, it make sense they are tied, and also avoid an extra CI round for no reason.

The inlining of the check is going to require some more work (managing the includes so we don't deal with circular dependencies)
But I can work on that after this is merged.

I also need to deal with regressions from enabling the check on release anyways, so this could be grouped with that

Thanks! LGTM