[llvm-dev] [cfe-dev] [RFC] Adding support for clang-format making further code modifying changes (original) (raw)
Andrew Tomazos via llvm-dev llvm-dev at lists.llvm.org
Sat Aug 28 14:39:00 PDT 2021
- Previous message: [llvm-dev] [cfe-dev] [RFC] Adding support for clang-format making further code modifying changes
- Next message: [llvm-dev] [cfe-dev] [RFC] Adding support for clang-format making further code modifying changes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Sat, Aug 28, 2021 at 1:52 PM Arthur O'Dwyer via cfe-dev < cfe-dev at lists.llvm.org> wrote:
But because it (has the potential to) change the token sequence, it is *qualitatively more dangerous* than a formatter that merely reformats the existing token sequence.
Formally new-line is not a preprocessing-token, but it is effectively, as it is referred to as a terminal in the preprocessor grammar. If we consider a new-line a preprocessor token, then I think it is almost the case that any source code change that does not change the preprocessor token sequence is unobservable in the final program. (For the true pedants there is std::source_location::column.)
But regardless of the formal proof: I think most people perceive the two general buckets "whitespace formatting" and "non-whitespace refactoring", and that the latter is more dangerous. Hence the suggestion of shipping two different frontend programs to help users isolate those two buckets if they so desire. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20210828/8ccb5749/attachment.html>
- Previous message: [llvm-dev] [cfe-dev] [RFC] Adding support for clang-format making further code modifying changes
- Next message: [llvm-dev] [cfe-dev] [RFC] Adding support for clang-format making further code modifying changes
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]