internal: Standardize how we take iterator parameters in SyntaxFactory
#18718
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In my PR for migrating wrap/unwrap return type, I remarked about two different ways of taking many elements as a parameter, and it seemed like a matter of style at the time, but it turns out it actually matters a lot! Because if you provide a parameter taking
IntoIterator + Clone
using something a.map()
, in which you construct additional elements using the sameSyntaxFactory
you're providing the parameter to, then by the lazy nature of iterators, there will be a looming mutable borrow on theRefCell
formappings
, and the code will panic. So we need to becollect
ing the iterator to force any internal references be dropped.