Add from_vec method for efficient creation from a Vec.

[SergioBenitez]

I also bumped the version to 0.3.3 for easy publishing.

---

This change is 

[emilio]

Could you add a few tests for this? In particular, an empty vector pointer may not be an actual valid pointer IIRC (may be 0x1?).

[SergioBenitez]

Sure, added.

[emilio]

Oh, ok, so we don't rely on the validness of the pointer (we just rely on Vec for most of stuff). r=me then

@bors-servo r+

Thanks for doing this!

[bors-servo]

📌 Commit 0bf0141 has been approved by emilio

[bors-servo]

⌛ Testing commit 0bf0141 with merge 46ef708...

[SergioBenitez]

Well, we certainly take the raw pointer from Vec, but we do so via the public API. The documentation doesn't say anything about the pointer possibly being invalid.

[bors-servo]

☀️ Test successful - status-travis
Approved by: emilio
Pushing 46ef708 to master...

[emilio]

Well, we certainly take the raw pointer from Vec, but we do so via the public API. The documentation doesn't say anything about the pointer possibly being invalid.

Right, there's no guarantee about that AFAIK. See https://bugzilla.mozilla.org/show_bug.cgi?id=1344209, which is the reason I was wary of this.

[SergioBenitez]

Looking at the source code for Vec, ptr will indeed be some constant, invalid value when the Vec is empty (alloc::heap::EMPTY). However, the ptr will only be this value when capacity/length are zero or T is a zero-sized type. As a result, SmallVec should never dereference the invalid pointer, and everything should work exactly as expected.

In the bug you linked, it seems that the fix was to use a null pointer when the string is empty. Presumably this is because some of the Core Foundation/Foundation code checks the ptr value for nullness to determine if it can be dereferenced. None of the code in SmallVec does this, another indication that everything is alright.

[emilio]

Right, it's not about core foundation, but Gecko's code, but that's right :)