Remove SET_ENCLOS() usage
#1847
Merged
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.
By making
r_env_poke_parent()usebase::parent.env<-.r_env_poke_parent()is now also internal to rlang and is not in the rlang C API.It's worth looking at https://github.com/r-lib/rlang/blob/main/src/internal/eval-tidy.c to see the places where we currently use
r_env_poke_parent(). I don't think any of them are particularly performance sensitive?The R level
env_poke_parent()still does the additional checks on top of whatbase::parent.env<-already does viaffi_env_poke_parent(). This lets us throw good error messages and I don't think it really costs us much. No one on CRAN (bundle, carrier, sparklyr) seems to be using this in a performance sensitive way anyways.https://github.com/search?q=org%3Acran+env_poke_parent&type=code
The C level
r_env_poke_parent()doesn't do any checks beyond whatbase::parent.env<-does, so it is up to the caller to ensure the data types are right, otherwise you'll get an error from base R, which may be suboptimal (but should never crash).