[stdlib] Work around the materialization bug present in #2825

[gabrieldemarmiesse]

This PR solves part of #2467

This PR is part of three PRs to read and merge in the following order

• [stdlib] Add optional small buffer optimization to List, take 2 #2825
• [stdlib] Work around the materialization bug present in #2825 #2826
• [stdlib] Add SSO to String by using SBO in List with materialization workaround #2827

The important diff is the one between this branch and the branch of the PR #2825 .

You can take a look at this diff here: gabrieldemarmiesse/mojo@sbo_take_2...gabrieldemarmiesse:mojo:fix_materializing
As you can see it's fairly small.

The bug

To understand the workaround, one must understand the bug.
This PR is here to work around the issue #2637
Long story short, when materializing a struct, if the struct holds a pointer to one of its elements, the compiler is a bit lost and will call __del__ on a struct with the pointer value not updated. (I think it moves the data but doesn't change the pointer value accordingly).
This causes us to call free() on a pointer that points to stack allocated data, because we check if SBO is in use by using self.data == self._small_buffer.unsafe_ptr(). Thus crashing the program. And it's really common to materilize things, especially with Strings that have default values in signatures.

The workaround

We don't trust the compiler to copy pointers to some elements of self, but we trust the compiler to copy correctly a bool. As such, we add a flag to know if sbo is in use or not, and we use it. This flag can be removed when the compiler bug is fixed.

Consequences on the default List

Because of this flag, List has one more byte. I wanted to add this flag only when using a small_buffer_size > 0 (you pay for what you use and all that), so I wanted to store this flag inside an InlineArray[Bool, Int(Self.sbo_enabled)], so that it doesn't take space when small_buffer_size = 0. At first, this worked. Then another compiler bug was introduced the 25/05/2024 which @JoeLoser managed to biscect down to some given commit. (feel free to link it here @JoeLoser ). Thus the InlineArray wasn't an option anymore and a simple permanant Bool must be used. Users will see List take one more byte until one of those two bugs are fixed.

Storing the flag inside the capacity or size at the most significant bit

This is an option to save one byte. But since the workaround is supposed to be temporary, I chose to avoid adding complexity (and possibly bugs) to the codebase for something like that. Furthermore, it doesn't impact performance much (see the next benchmarks), it only increases the size of the List.

[JoeLoser]

!sync