catchr and rlang 1.0.0

[lionel-]

Hello,

I'm seeing several errors with dev rlang. We plan to release it in 2 to 4 weeks. With R CMD check I see these two:

check_and_clean_input(d1 = base::acosh, spec_names = "acosh")
#> Error in `call_name()`: `call` must be a simple call.
#> ℹ Calls to `::` or `:::` are not simple calls.
#> ℹ See `?is_call_simple`.


opts <- catchr_opts(
  default_plan = c(collect, muffle),
  drop_empty_conds = FALSE,
  bare_if_possible = FALSE
)
plans <- make_plans(warning, message, error, .opts = opts)

res <- catch_expr(condition_thrower(), plans)
res2 <- catch_expr(dispense_collected(res), plans)
waldo::compare(res, res2)
#> `old$error[[1]]` is length 2
#> `new$error[[1]]` is length 3
#>
#> `names(old$error[[1]])`: "message" "call"
#> `names(new$error[[1]])`: "message" "call" "trace"
#>
#> `old$error[[1]]$trace` is absent
#> `new$error[[1]]$trace` is an S3 object of class <rlang_trace/rlib_trace/tbl/data.frame>, a list

The call_name() error is a planned breakage, it now needs to be paired with is_call_simple().

I see more issues with interactive devtools::test() but haven't investigated. Could you take a look and let me know if you think there is any bug in rlang that causes failures please?

[lionel-]

I've changed call_name(quote(foo::bar)) to return NULL instead of failing. This way it still composes well with is_call(): if input is a call, call_name() and call_ns() never fail, but might return NULL with complex calls for which is_call_simple() is FALSE.

This still leaves this error:

check_and_clean_input(d1 = base::acosh, spec_names = "acosh")
#> Error in `if (is_call(x) && !(call_name(x) %in% c("::", ":::"))) ...`:
#> missing value where TRUE/FALSE needed

I think you can change your check to is_call(x) && is_simple_call(x). Even with CRAN rlang your current check would fail in case of complex calls like foo()() or foo$bar().

[lionel-]

Hello. The .subclass argument of abort(), warn() and inform() has been renamed to class in rlang 0.4.2 (released in November 2019).

No rush but could you please look into renaming any occurrences of .subclass in your package?