rcnst issue with reverse dependency (TeXCheckR)

[HughParsonage]

Thank you very much for fastmatch. I'm using it in a package but I've been notified by CRAN of an rcnst issue that seems to be associated with fastmatch. I posted in the R-package-dev mailing list seeking advice but haven't received a reply there. The guidelines in the CRAN documentation for rcnst issues suggest getting in contact with the maintainer of an imported package if that package might be the cause; hence this issue. Apologies if I'm mistaken. Any help you could provide would be appreciated.

The package is TeXChecKR and the issue page for the rcnst issue is https://github.com/kalibera/cran-checks/tree/master/rcnst/results/TeXCheckR . The modified constant is c(".", "?"). TeXCheckR does not require compilation; it contains no C/C++ code.

The offending test has the following log:

Space inserted before \footnote
✖ 11: \footnote{\gls{HELP} lending, tuition funding, and most other higher education programs are special appropriations from consolidated government revenue.

ERROR: modification of compiler constant of type character, length 2
ERROR: the modified value of the constant is:
[1] "." "?"
attr(,".match.hash")
<hash table>
ERROR: the original value of the constant is:
[1] "." "?"
ERROR: the modified constant is at index 1
ERROR: the modified constant is in this function body:
c(".", "?")
Fatal error: compiler constants were modified!

I'm using the following line if (split_line_after_footnote[footnote_closes_at - 1] %notin% c(".", "?")){ where `%notin% is imported from the hutils package and is defined as:

`%notin%` <- function(x, y){
  if (is.null(y)) {
    rep_len(TRUE, length(x))
  } else {
    is.na(fmatch(x, y))
  }
}

I note in the documentation for fmatch, you remark

fmatch modifies the table by attaching an attribute to it. It is expected that the values will not change unless that attribute is dropped. Under normal circumstances this should not have any effect from user's point of view, but there is a theoretical chance of the cache being out of sync with the table in case the table is modified directly (e.g. by some C code) without removing attributes.

TeXCheckR alone does not modify table directly (or at least it has no C code with that intent), so I'm not sure if this part of the documentation is applicable.

Thank you again.