Delete non-ASCII characters from header #3588
Conversation
|
So weird. Personally I have to hold myself back from going crazy with UTF-8 in comments, |
|
Why are we still so picky about unicode? Don't all compilers support it in the source code by now? Are we worried about copy pasting invisible characters that could lead to all kinds of confusion? It sure would be nice to use greek letters in comments with equations (or even in identifier names!) |
In this case, the use of non-ASCII characters wasn't intentional, so it made sense to remove it. I'm not aware if we have a libMesh rule explicitly allowing or disallowing unicode characters either in comments or in actual code? Personally I think it's a little gimmicky and probably wouldn't use them much, but if people really want to do it, I guess it would be fine, maybe after one more ASCII-only release? |
|
Job Distributed make check sweep (even) on 1cfb948 : invalidated by @jwpeterson Retry after fixing CIVET |
|
Job Distributed make check sweep (odd) on 1cfb948 : invalidated by @jwpeterson Retry after fixing CIVET |
|
Job Min clang on 1cfb948 : invalidated by @jwpeterson Retry after fixing CIVET |
|
Job Min gcc on 1cfb948 : invalidated by @jwpeterson Retry after fixing CIVET |
|
Job Test 32bit on 1cfb948 : invalidated by @jwpeterson Retry after fixing CIVET |
|
Job Test MOOSE clang on 1cfb948 : invalidated by @jwpeterson Retry after fixing CIVET |
|
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2295r6.pdf Clang basically assumes everything is UTF-8, but GCC and MSVC require a special flag or environment, and other compilers ... were apparently not worth mentioning directly? But it looks like the "Edison Design Group" did the frontend for Portland Group compilers, from which NVidia's HPC stuff is descended, so maybe nvc++ is solid? I love writing with Unicode, but I'd just as soon wait until Unicode support is in an official standard, not just a common extension. I'd also worry a little bit about users' editor support, especially if we want to use unicode in identifiers. XCompose is what makes me happy to write with Unicode, but last I looked you have to get third party programs to make that work on Windows or Mac, and even on Linux I've been maintaining my own |
|
Job Test MOOSE debug on 1cfb948 : invalidated by @jwpeterson Retry after fixing CIVET |
|
Job Test MOOSE min clang on 1cfb948 : invalidated by @jwpeterson Retry after fixing CIVET |
|
Job Test MOOSE min gcc on 1cfb948 : invalidated by @jwpeterson Retry after fixing CIVET |
|
Job Test clang on 1cfb948 : invalidated by @jwpeterson Retry after fixing CIVET |
|
Job Test complex and infinite on 1cfb948 : invalidated by @jwpeterson Retry after fixing CIVET |
|
Job Test debug on 1cfb948 : invalidated by @jwpeterson Retry after fixing CIVET |
|
I'd also worry a little bit about visual conflicts. Does |
|
Job Test with threads on 1cfb948 : invalidated by @jwpeterson Retry after fixing CIVET |
|
Job Test mac on 1cfb948 : invalidated by @jwpeterson Retry after fixing CIVET |
|
Job Test debug on 1cfb948 : invalidated by @jwpeterson Retry after fixing CIVET |
|
Job Test complex and infinite on 1cfb948 : invalidated by @jwpeterson Retry after fixing CIVET |
|
Job Test clang on 1cfb948 : invalidated by @jwpeterson Retry after fixing CIVET |
|
https://civet.inl.gov/job/1598122/ is still failing, but at least this time the bug turns out to be "clang++-12 doesn't support -fsanitize-ignorelist like clang++-14 did", not "Roy can't write bash correctly" any more. |
|
Job Coverage on 1cfb948 wanted to post the following: CoverageNo coverage report(s) were found for the base commit 2a70c84. This comment will be updated on new commits. |
This is kind of a real fix, but also a test of whether CIVET is working again.