Forbid read-eval syntax in formatted/linted files

[vemv]

Brief

Forbid read-eval syntax in formatted/linted files

This particularly targets Eastwood (since it's the only member of our stack that evals code, and therefore can run read-eval syntax) and tools.reader (which we internally use for various purposes).

It also is bound at formatting-stack.core level in case any other mechanisms happen to be sensitive.

Fixes #158

QA plan

• Lint formatting-stack itself via the project or branch formatter
  • Note that Eastwood will complain due to the two test namespaces that intentionally fail (functional.formatting-stack.linters.eastwood.examples.read-eval, functional.formatting-stack.linters.eastwood.examples.read-eval-2)
  • Note that they must be placed in test and not test-resources, since ns parsing (and refresh-dirs parsing) is part of how our Eastwood integration works
  • This can be slightly inconvenient in a future when we dogood f-s in CI (not done atm), by then we could simply exclude these two files with a strategy.

Author checklist

• I have QAed the functionality
• The PR has a reasonably reviewable size and a meaningful commit history
• I have run the branch formatter and observed no new/significative warnings
• The build passes
• I have self-reviewed the PR prior to assignment
• Additionally, I have code-reviewed iteratively the PR considering the following aspects in isolation:
  • Correctness
  • Robustness (red paths, failure handling etc)
  • Test coverage
  • Spec coverage
  • Documentation
    • Worth adding an explanation to the https://github.com/nedap/formatting-stack/wiki/FAQ
  • Security
  • Performance
  • Breaking API changes
    • Strictly speaking this would break a consumer that used #=() syntax. However #= is not part of the Clojure API: it's absent from https://clojure.org/reference/reader#_dispatch , https://clojure.org/guides/weird_characters
    • I do think it's good that f-s communicates that using #=() is a problem. My experience was that #=() can be detected and fixed.
  • Cross-compatibility (Clojure/ClojureScript)

Reviewer checklist

• I have checked out this branch and reviewed it locally, running it
• I have QAed the functionality
• I have reviewed the PR
• Additionally, I have code-reviewed iteratively the PR considering the following aspects in isolation:
  • Correctness
  • Robustness (red paths, failure handling etc)
  • Test coverage
  • Spec coverage
  • Documentation
  • Security
  • Performance
  • Breaking API changes
  • Cross-compatibility (Clojure/ClojureScript)

[vemv]

Not ready yet:

defecord constructor syntax (#formatting_stack.strategies.foo.Foo[:a]) inherently uses read-eval. This alone shouldn't prevent a file from being formatted/linted.

Instead one could detect if there's #= in a given file (using e.g. rewrite-clj), and bind *read-eval* accordingly.

[vemv]

Personally I'm not that interested in forbidding read-eval anymore. Or at least under a direct approach. It just gives too many problems IME - read-eval is sprinkled throughout Clojure internals so disabling it can be problematic.

Another approach would be linting this 'syntactically' i.e. with rewrite-clj.