Error rendering errorneous code in R chunk (maybe rlang errors specifically?)

[eternal-flame-AD]

Reproduction:

Put this incorrect code in an empty Rmd or Quarto file (can't reproduce on reprex for some reason).

```{r}
library(tidyverse)

mtcars %>%
    ggplot(aes(x = wt, y = mpg)) +
    geom_qq() +
    geom_smooth(method = "lm")
```

For reproduction, I tried (1) the latest conda-forge and (2) my local environment which has updated all packages, latest R on my distro and pulled the github version of knitr as you requested, both exhibit this issue:

I was expecting to see the ggplot error telling me this makes no sense, but I get this:

Error in `!continue`:
! invalid argument type
Backtrace:
  1. global .main()
  2. execute(...)
  3. rmarkdown::render(...)
  4. knitr::knit(knit_input, knit_output, envir = envir, quiet = quiet)
  5. knitr:::process_file(text, output)
     ...
  9. knitr:::call_block(x)
 10. knitr:::block_exec(params)
 11. knitr:::eng_r(options)
 14. knitr (local) evaluate(...)
 15. evaluate::evaluate(...)

This happens a lot in my real work recently and I don't remember it happening before and I had to resort to manually attaching error=true to the chunk to get the real error. I have these thoughts:

• This doesn't happen with base R stop(), only those "rich" errors through rlang, I wasn't really conscious to record all the data so I can't say 100% but it feels like it.
• Not 100% sure it's knitr or something more upstream because reprex didn't break, I opened here because the stack trace shows this and this issue: Quarto Tikz Error quarto-dev/quarto-cli#10481
• I made some trivial version changes through conda and didn't resolve it.
• I am willing to submit a PR for this if needed, but definitely would like you to look at it first to see if it's something else.

Thanks!

R version 4.4.1 (2024-06-14)
Platform: x86_64-pc-linux-gnu
Running under: Arch Linux

Locale:
  LC_CTYPE=en_US.UTF-8       LC_NUMERIC=C               LC_TIME=en_US.UTF-8        LC_COLLATE=en_US.UTF-8     LC_MONETARY=en_US.UTF-8   
  LC_MESSAGES=en_US.UTF-8    LC_PAPER=en_US.UTF-8       LC_NAME=C                  LC_ADDRESS=C               LC_TELEPHONE=C            
  LC_MEASUREMENT=en_US.UTF-8 LC_IDENTIFICATION=C       

Package version:
  base64enc_0.1.3   bslib_0.8.0       cachem_1.1.0      cli_3.6.3         digest_0.6.37     evaluate_1.0.0    fastmap_1.2.0     fontawesome_0.5.2
  fs_1.6.4          glue_1.8.0        graphics_4.4.1    grDevices_4.4.1   highr_0.11        htmltools_0.5.8.1 jquerylib_0.1.4   jsonlite_1.8.9   
  knitr_1.48.5      lifecycle_1.0.4   memoise_2.0.1     methods_4.4.1     mime_0.12         R6_2.5.1          rappdirs_0.3.3    rlang_1.1.4      
  rmarkdown_2.28    sass_0.4.9        stats_4.4.1       tinytex_0.53      tools_4.4.1       utils_4.4.1       xfun_0.47         yaml_2.3.10      

Pandoc version: 3.1.9

For conda reproduction:

[project]
authors = ["eternal-flame-AD <[email protected]>"]
channels = ["conda-forge"]
description = "Add a short description here"
name = "knitr-rlang-error"
platforms = ["linux-64"]
version = "0.1.0"

[tasks]

[dependencies]
quarto = ">=1.5.57,<2"
r-knitr = ">=1.48,<2"
r-rmarkdown = ">=2.28,<3"
r-tidyverse = ">=2.0.0,<3"
r = ">=4.4,<5"
bash = ">=5.2.21,<6"
coreutils = ">=9.5,<10"
which = ">=2.21,<3"

---

By filing an issue to this repo, I promise that

• I have fully read the issue guide at https://yihui.org/issue/.
• I have provided the necessary information about my issue.
  • If I'm asking a question, I have already asked it on Stack Overflow or RStudio Community, waited for at least 24 hours, and included a link to my question there.
  • If I'm filing a bug report, I have included a minimal, self-contained, and reproducible example, and have also included xfun::session_info('knitr'). I have upgraded all my packages to their latest versions (e.g., R, RStudio, and R packages), and also tried the development version: remotes::install_github('yihui/knitr').
  • If I have posted the same issue elsewhere, I have also mentioned it in this issue.
• I have learned the Github Markdown syntax, and formatted my issue correctly.

I understand that my issue may be closed if I don't fulfill my promises.

[cderv]

Thanks for the report. I believe this is linked to newest evaluate version. Though it is not related to Quarto directly. It happens in Quarto because R is ran is a background session, and it seems to be the problem;

I can reproduce with knitr only

> xfun::Rscript_call(\() { knitr::opts_chunk$set(error = FALSE); knitr::knit("test.qmd")})
++ Activating rlang global_entrace



processing file: test.qmd
  |....................................................| 100% [unnamed-chunk-1]Error in `!continue`:
! type de l'argument incorrect
Backtrace:
  1. knitr::knit("test.qmd")
  2. knitr:::process_file(text, output)
  5. knitr:::process_group(group)
  6. knitr:::call_block(x)
  7. knitr:::block_exec(params)
  8. knitr:::eng_r(options)
 11. knitr (local) evaluate(...)
 12. evaluate::evaluate(...)

Quitting from lines 7-13 [unnamed-chunk-1] (test.qmd)
                                                                                                            
Exécution arrêtée
Error:
! Failed to run 'function() {' in a new R session: Erreur dans !continue : 
Appels : local ... .handleSimpleError -> h -> <Anonymous> -> cnd_signal -> signal_abort
Run `rlang::last_trace()` to see where the error occurred.

I'll look into it.

[cderv]

This is probably where the problem is coming from
https://github.com/r-lib/evaluate/blob/8e0f5e8f78a4402957a4bd9c25972ed910a8a685/R/evaluate.R#L141-L161

[cderv]

So here is more minimal example

---
title: "test"
---

```{r error = FALSE}
rlang::abort("Test")
```

Using Render button on RStudio IDE will run this in background session and we get

==> rmarkdown::render('C:/Users/chris/Documents/DEV_R/evaluate/test.Rmd',  encoding = 'UTF-8');
++ Activating rlang global_entrace

  |....................................................| 100% [unnamed-chunk-1]

processing file: test.Rmd
                                                                                                            
Error in `!continue`:
! type de l'argument incorrect
Backtrace:
  1. rmarkdown::render(...)
  2. knitr::knit(knit_input, knit_output, envir = envir, quiet = quiet)
  3. knitr:::process_file(text, output)
  6. knitr:::process_group(group)
  7. knitr:::call_block(x)
  8. knitr:::block_exec(params)
  9. knitr:::eng_r(options)
 12. knitr (local) evaluate(...)
 13. evaluate::evaluate(...)

Quitting from lines 6-7 [unnamed-chunk-1] (test.Rmd)
Exécution arrêtée

Running in R console leads to the same error

> rmarkdown::render("test.Rmd")


processing file: test.Rmd
  |.............................................................................................................................................................| 100% [unnamed-chunk-1]Error in `!continue`:
! type de l'argument incorrect
Backtrace:
  1. rmarkdown::render("test.Rmd")
  2. knitr::knit(knit_input, knit_output, envir = envir, quiet = quiet)
  3. knitr:::process_file(text, output)
  6. knitr:::process_group(group)
  7. knitr:::call_block(x)
  8. knitr:::block_exec(params)
  9. knitr:::eng_r(options)
 12. knitr (local) evaluate(...)
 13. evaluate::evaluate(...)

Quitting from lines 6-7 [unnamed-chunk-1] (test.Rmd)

And knitr::knit() the same

> knitr::knit("test.Rmd")


processing file: test.Rmd
  |.............................................................................................................................................................| 100% [unnamed-chunk-1]Error in `!continue`:
! type de l'argument incorrect
Backtrace:
  1. knitr::knit("test.Rmd")
  2. knitr:::process_file(text, output)
  5. knitr:::process_group(group)
  6. knitr:::call_block(x)
  7. knitr:::block_exec(params)
  8. knitr:::eng_r(options)
 11. knitr (local) evaluate(...)
 12. evaluate::evaluate(...)

Quitting from lines 6-7 [unnamed-chunk-1] (test.Rmd)

I can't reproduce with evaluate only so I need to look closer on how this works withRestarts works.

[eternal-flame-AD]

The upstream has fixed the issue and I tested this will fix this issue, a potential improvement on error reporting we can continue on #2369