rename `SmallVec.len` field to `length`

[alejandro-vaz]

to avoid many subtle development mistakes and the IDE going crazy

simply rename the field and everywhere it is used

also rename all other occurrences of variable len (except the len method) to length

[Denimworld12]

I'd like to take this, but I think it wants sequencing rather than doing right now — flagging before I open anything.

I counted the occurrences on current v2:

	count
len identifiers to rename	226
.len() / fn len( to keep	88
len inside comments	60

So it lands as ~226 mechanical edits across lib.rs, rawsmallvec.rs, iterators/drain.rs, iterators/extractif.rs and taggedlen.rs.

The problem is what's already open on those same files:

• refactor: simpler raw #637 refactor: simpler raw — lib.rs, rawsmallvec.rs, touches 6 lines containing len
• refactor: new error system #624 refactor: new error system — lib.rs, rawsmallvec.rs, drain.rs, touches 8 lines containing len

A rename this wide would conflict with both, and whichever merges second eats the rebase. A mechanical rename is cheap to redo from scratch and expensive to hold open through someone else's refactor, so it seems better for it to go last.

My suggestion: land #637 and #624 first, then I do this in one pass against whatever v2 looks like at that point. Ping me here and I'll turn it around quickly.

Two scope questions while it waits, both from the "except the len method" line:

1. Comments — 60 occurrences. Some describe the variable (// SAFETY: len < tail_start <= capacity), which should follow the rename; others describe the method (// allowed to call iter.len()), which shouldn't. I'd update the first kind only, unless you'd rather I leave all comments alone.
2. Locals shadowing the method — e.g. let len = vec.len(); becomes let length = vec.len();. I read that as in scope, since it's a variable, but say if you meant only the field and its direct uses.

Happy to do it now instead if you'd rather not wait — it's your call on the ordering, I just didn't want to hand you an avoidable conflict.

[alejandro-vaz]

it's just 6+8 lines so it's not worth worrying about it

it'll create merge conflicts in those PRs anyway, so when updating we make sure they are alright

please, don't use generative AI for talking here, it goes against the @servo contributing guidelines

I've assigned you

go ahead now

[Denimworld12]

Hi Alejandro, I want to be transparent about something I realized after your comment. I used an AI assistant while working on #641, #642, and the #636 comment, including for the code and written portions. I hadn't checked Servo's contribution policy beforehand, and I've since read it and understand that this isn't permitted.

That's my mistake. I won't make the requested #636 changes using AI. For the existing PRs, I'm happy to redo the work myself or close them, whichever you prefer. Sorry for putting you in this position, and thanks for pointing me to the policy.

[alejandro-vaz]

no worries, keep the existing work, no need to remake it

I'll make the wording on the readme clearer

[alejandro-vaz]

do you still want to implement #636?? @Denimworld12

[Denimworld12]

Yes, I’d still like to implement #636.

[alejandro-vaz]

go ahead and I'll review it