Skip to content

Compatibility with R 4.6#1083

Open
lionel- wants to merge 8 commits intotask/r-dev-testsfrom
task/r-devel-compat
Open

Compatibility with R 4.6#1083
lionel- wants to merge 8 commits intotask/r-dev-testsfrom
task/r-devel-compat

Conversation

@lionel-
Copy link
Contributor

@lionel- lionel- commented Mar 4, 2026

Branched from #1076

R core just removed access to a bunch of APIs, just in time to put our new r-devel build (#1076) to good use.

Screenshot 2026-03-04 at 18 11 17

The main change is that we no longer unlock our private namespaces and environments. Instead we wait until they are fully initialised to lock them. In debug builds we never lock them to allow hot-reloading when a .R file changes.

Otherwise we follow what we've been doing in rlang, lobstr, vctrs, and other packages regarding compatibility with C API. E.g. in zap_srcref() or obj_size(). We use new APIs (with polyfills for old R compats) or new workaround approaches.

I've also proactively removed usage of ATTRIB() and SET_ATTRIB() as well (except in the altrep utils) since these have been promoted from NOTE to WARNING on CRAN.

@lionel- lionel- force-pushed the task/r-devel-compat branch from e544706 to 354298d Compare March 4, 2026 17:17
@lionel- lionel- requested a review from DavisVaughan March 4, 2026 17:41
Comment on lines -129 to +133
unsafe { libr::OBJECT(object) != 0 }
unsafe { libr::Rf_isObject(object) != 0 }
}

pub fn r_is_s4(object: SEXP) -> bool {
unsafe { libr::IS_S4_OBJECT(object) != 0 }
unsafe { libr::Rf_isS4(object) != 0 }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you please go through r.rs and remove anything we no longer need? Like I see OBJECT and IS_S4_OBJECT are still in there, and it would be nice to remove them so we don't accidentally use them again.

Comment on lines -163 to -164
// First replace the body which contains expressions tagged with srcrefs
// such as calls to `{`. Compiled functions are a little more tricky.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Outdated? Dropped?

}

/// Creates a closure.
pub unsafe fn new_function(formals: SEXP, body: SEXP, env: SEXP) -> SEXP {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you want it to be unsafe?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nope!

Comment on lines +62 to +75
compat::alloc_closure(formals, body, env)
}
}

mod compat {
use libr::SEXP;

pub unsafe fn alloc_closure(formals: SEXP, body: SEXP, env: SEXP) -> SEXP {
let out = libr::Rf_allocSExp(libr::CLOSXP);
libr::SET_FORMALS(out, formals);
libr::SET_BODY(out, body);
libr::SET_CLOENV(out, env);
out
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it feels more useful to me to just inline this. we'd only ever use it in this 1 place probably?

Comment on lines +114 to +119
/// Copies all attributes from `src` to `dst`.
pub fn attrib_poke_from(dst: SEXP, src: SEXP) {
attrib_for_each(src, |tag, val| unsafe {
libr::Rf_setAttrib(dst, tag, val);
});
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not DUPLICATE_ATTRIB or SHALLOW_DUPLICATE_ATTRIB?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants