fix: vec! macro resolution via alloc::vec self-import

[ravi-ciroos]

Problem

use alloc::vec::{self, Vec}; at the top of src/tinyvec.rs relies on the
self import also bringing the vec! macro into scope alongside the vec
module. On some toolchains that import only resolves the module (type
namespace), not the macro, so the unqualified vec![...] calls in this file
fail to compile with:

error: cannot find macro `vec` in this scope
   --> src/tinyvec.rs:710:21
    |
710 |       TinyVec::Heap(vec![A::Item::default(); len])
    |                     ^^^
    |
note: `vec` is imported here, but it is a module, not a macro
   --> src/tinyvec.rs:3:18
    |
  3 | use alloc::vec::{self, Vec};
    |                  ^^^^

Toolchains where this reproduces

Reproduced building tinyvec 1.13.0 (--features alloc) on all three rustc
versions available to me, so it isn't specific to one release:

rustc	commit	date
1.94.1	e408947bf	2026-03-25
1.95.0	59807616e	2026-04-14
1.98.1 (latest stable)	48a229cea	2026-09-01

(rustc --version --verbose output for each attached below.)

rustc 1.94.1 (e408947bf 2026-03-25)
host: aarch64-apple-darwin
LLVM version: 21.1.8

rustc 1.95.0 (59807616e 2026-04-14)
host: aarch64-apple-darwin
LLVM version: 22.1.2

rustc 1.98.1 (48a229cea 2026-09-01)
host: aarch64-apple-darwin
LLVM version: 22.1.8

This surfaced downstream via unicode-normalization (pulled in transitively
through lancedb → lance → lance-tokenizer), which depends on
tinyvec's alloc feature and hits this exact code path.

Fix

• Import Drain by name instead of importing the vec module via self.
• Fully qualify the two vec! call sites (alloc::vec! and
  $crate::alloc::vec! inside the exported tiny_vec! macro) so macro
  resolution no longer depends on the self-import behavior.

Verified cargo build --features alloc succeeds with this change on all
three toolchains listed above.

[developer0hye]

The macro-specific hunk is still needed after #226. I reproduced a remaining failure on current main from a downstream #![no_std] crate:

#![no_std]
use tinyvec::{tiny_vec, TinyVec};

fn expands_to_heap() -> TinyVec<[u8; 1]> {
  tiny_vec!([u8; 1] => 1, 2)
}

The library-only check added by #226 passes, but this downstream expansion fails with cannot find macro vec in this scope. Your $crate::alloc::vec! change fixes it.

To make that fix durable, please add a #![no_std] integration target that expands the heap arm and run:

cargo check --test no_std_macro --no-default-features --features=alloc

I verified that command fails before the macro hunk and passes at 03a1781. It also coexists with the normal std test configuration. Since #226 has now merged, rebasing this PR would also make the remaining macro-only change clearer.

[Lokathor]

I think this came in almost exactly as I was merging and releasing #226 .

I understand that #226 wasn't a complete fix in all cases, so I'm happy to take further submissions if you rebase and adjust.

Adding a CI pass that checks this extra edge case situation would also be greatly appreciated.

[rchamarthy]

@Lokathor @developer0hye - I rebased to the latest main and updated the PR. Please review.

[ravi-ciroos]

@Lokathor would it possible to cut a release tag for me to use for our project. Thank you.

[andrew-signal]

Ah! Sorry I missed this behavior on these other toolchains. Thanks for fixing this up!

[Lokathor]

@ravi-ciroos i use cargo release these days so all releases get a github tag. this is in 1.13.2, if you didn't already notice.