chore: update clarity

[hugocaillard]

Description

Use feat/clarity-wasm-develop instead of feat/clarity-wasm-next. See this here: https://github.com/stacks-network/stacks-core/pull/4756

A few breaking changes had to be addressed:

• some functions were renamed
• tuple type signature has been replaced by an hashmap instead of btreemap (https://github.com/stacks-network/stacks-core/pull/4614), breaking the usage of .rev() on this repo
• run_analysis takes a new arguments build type map (same PR as above), I set to true but maybe it can be optimized

[codecov[bot]]

Codecov Report

Attention: Patch coverage is 89.28571% with 6 lines in your changes are missing coverage. Please review.

Project coverage is 87.02%. Comparing base (c08377f) to head (1c6679e).

Files	Patch %	Lines
clar2wasm/src/datastore.rs	50.00%	2 Missing :warning:
clar2wasm/src/wasm_utils.rs	90.00%	2 Missing :warning:
clar2wasm/src/words/tuples.rs	86.66%	0 Missing and 2 partials :warning:

Additional details and impacted files

```diff @@ Coverage Diff @@ ## main #400 +/- ## ========================================== + Coverage 86.97% 87.02% +0.04% ========================================== Files 43 43 Lines 18386 18392 +6 Branches 18386 18392 +6 ========================================== + Hits 15992 16006 +14 + Misses 1054 1046 -8 Partials 1340 1340 ```

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[csgui]

The analysis performance was improved, in the stacks-core, by simplifying the TypeMap struct to a HashSet, but this is only used by tests and docs generation. So, wouldn't make sense to have the ability to change the build_type_map to false when running tests? I mean, doesn't make sense to make the build_type_map configurable somehow?

[Acaccia]

@csgui As you might know, the typechecker is broken: it doesn't set the correct types in many cases. We always need a real TypeMap (which as its name says, should be a map) so that we can workaround it until we have the time to rewrite a correct typechecker.

The analysis performance was improved, in the stacks-core, by simplifying the TypeMap struct to a HashSet

Where is the source for this? I just heard there was an improvement when going from a BTreeMap to a HashMap personally.

[csgui]

Where is the source for this? I just heard there was an improvement when going from a BTreeMap to a HashMap personally.

@Acaccia It's on this PR for stacks core

https://github.com/stacks-network/stacks-core/pull/4614#issue-2220984211

https://github.com/stacks-network/stacks-core/blob/master/clarity/src/vm/analysis/type_checker/contexts.rs#L33

[Acaccia]

@chris there are no numbers on this PR proving the efficiency of the change.

stacks-network/stacks-core@master/clarity/src/vm/analysis/type_checker/contexts.rs#L33

What is this link for?

[csgui]

This simply links to a comment giving more details about the usage of the different TypeMaps.

[hugocaillard]

So this is not ready to be merged yet right?

[Acaccia]

I believe everything is good from my point of view.

[csgui]

Also good from my side. The topic I added was to encourage discussion, not to suggest particular modifications for this PR.

[hugocaillard]

Had to fix the conflicts. @Acaccia it was conflicting with your latest merged PR, can you double check the fix please? Thx