Reimplement markdown escaping in C++

[hadley]

x <- r"(See \code{foo()} and \link{bar})"
y <- strrep("x", 1e3)

bench::mark(
  escape_rd_for_md_c(x),
  escape_rd_for_md_c(y),
  check = FALSE
)[1:5]

This branch:

  <bch:expr>            <bch:tm> <bch:tm>     <dbl> <bch:byt>
1 escape_rd_for_md_c(x)   2.34µs   3.32µs   248920.        0B
2 escape_rd_for_md_c(y)   4.39µs   4.67µs   206356.        0B

Main branch:

# A tibble: 2 × 5
  expression               min   median `itr/sec` mem_alloc
  <bch:expr>          <bch:tm> <bch:tm>     <dbl> <bch:byt>
1 escape_rd_for_md(x)    154µs    170µs     5688.    3.56KB
2 escape_rd_for_md(y)    109µs    121µs     8112.   64.07KB

[hadley]

@gaborcsardi could you take a bit of a look at this? I'm not 100% convinced that it's worth reviewing this code but it is a lot faster, and I think underlying ideas are actually a bit easier to see in C++. This function is called on just about every tag component, so it is a reasonable place to optimise.

[gaborcsardi]

Was this a bottleneck in devtools::document()?

According to my not very sophisticated timings, this PR does make devtools::document() very slightly (3-4%) faster for some packages (ps, processx, rlang), and has essentially no effect for others (testthat). E.g. this is testthat:
Before:

> system.time(devtools::document())
ℹ Updating testthat documentation
ℹ Loading testthat
   user  system elapsed
  1.520   0.171   1.845

After:

> system.time(devtools::document())
ℹ Updating testthat documentation
ℹ Loading testthat
   user  system elapsed
  1.501   0.173   1.836

(The fastest runs for each case from several runs.)

The C++ code seems mostly straightforward. The risk I see is that there might be edge cases we don't anticipate. I tried it on a bunch of packages, it seems to be OK, but people might be doing weird things. Should that happen, they can still use an older roxygen2 until we fix up the edge cases. So if you think that this code is better and easier to maintain, then we should merge it.

Btw. to speed this up further for repeated runs, we could memoize this function.

[gaborcsardi]

Are these changes expected?

[gaborcsardi]

Is this change expected?

[gaborcsardi]

I think it would make sense to generated this list programmatically instead of repeating it.

[hadley]

It's now in a C++ vector, so not easy to pull. But given that it changes rarely and there's a reminder comment in the C++ code (which claude is likely to read), I think it's low risk.

[gaborcsardi]

We can add a c++ function that just returns that vector as an R character vector, no?

[gaborcsardi]

I think the next character can also be a [, e.g. \link[=dest]{name}.