refactor(ast/ast_builder)!: shorter allocator utility method names.

[rzvxa]

This PR serves two purposes, First off it would lower the amount of characters we have to type in for a simple operation such as wrapping an expression in a vector. Secondly, it would follow the generated names more closely since nowhere else in the builder we do have new_xxx, We always say xxx since a builder always constructs something.

new_vec -> vec
new_vec_single -> vec1*
new_vec_from_iter -> vec_from_iter
new_vec_with_capacity -> vec_with_capacity
new_str -> str
new_atom -> atom

* This one is the main motivation behind this PR, It saves 10 characters!

[rzvxa]

• feat(ast): allow conversion from Expression into Statement with FromIn trait. #4124
• refactor(ast/ast_builder)!: shorter allocator utility method names. #4122 👈
• feat(ast_codegen): add cli arguments to use with oxc_ast_codegen executable. #4117
• refactor(ast_codegen): cleanup usages of the generated outputs. #4116
• feat(ast)!: generate ast_builder.rs. #3890
• feat(ast_codegen): add ast builder generator. #4098
• feat(span): add various implementations of FromIn for Atom. #4090
• feat(allocator): introduce FromIn and IntoIn traits. #4088
• main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @rzvxa and the rest of your teammates on Graphite

[graphite-app]

Your org has enabled the Graphite merge queue for merging into main

Add the label “merge” to the PR and Graphite will automatically add it to the merge queue when it’s ready to merge. Or use the label “hotfix” to add to the merge queue as a hot fix.

You must have a Graphite account and log in to Graphite in order to use the merge queue. Sign up using this link.

[codspeed-hq]

CodSpeed Performance Report

Merging #4122 will not alter performance

_{Comparing 07-08-refactor_ast_ast_builder_shorter_allocator_utility_method_names (b936162) with main (e29cdbf)}

Summary

✅ 29 untouched benchmarks

[overlookmotel]

I agree with the logic of this change. I'd suggest vec_from_iter rather than vec_from. That might be an abbreviation too far (from what?) - and also it's not much used.

[overlookmotel]

I still prefer vec_from_iter as it matches std's naming convention (Vec::from_iter also accepts anything which can be iterated). We could conceivably want to add e.g. vec_from_slice later on. But I don't feel so strongly about it.

[rzvxa]

I agree with the logic of this change. I'd suggest vec_from_iter rather than vec_from. That might be an abbreviation too far (from what?) - and also it's not much used.

At first, I thought it was accepting iterators before so I sent a false comment. I removed it to write an accurate answer instead.

I chose this name because it doesn't accept Iterator, It accepts IntoIterator which can be a variety of things such as Some(T) so that's why I went with this generic name. Let me know if you don't follow my reasoning or if you have a relatively strong objection, I'm flexible for changing it.

[rzvxa]

I still prefer vec_from_iter as it matches std's naming convention (Vec::from_iter also accepts anything which can be iterated). We could conceivably want to add e.g. vec_from_slice later on. But I don't feel so strongly about it.

I agree with your reasoning, Just pushed a new commit addressing this.

[graphite-app]

Merge activity

• Jul 8, 11:40 PM EDT: Boshen added this pull request to the Graphite merge queue.
• Jul 8, 11:55 PM EDT: The Graphite merge queue couldn't merge this PR because it was not satisfying all requirements (Failed CI: 'Format').
• Jul 9, 8:12 AM EDT: The merge label 'merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
• Jul 9, 8:16 AM EDT: rzvxa added this pull request to the Graphite merge queue.
• Jul 9, 8:20 AM EDT: rzvxa merged this pull request with the Graphite merge queue.