[PATCH] D65956: clang: Diag running out of file handles while looking for files

karies added a comment. Herald added a project: All. Similar to the concern raised at https://github.com/llvm/llvm-project/commit/50fcf7285eeb001d751eadac5d001a0e216fd701 we have received user reports about this patch: with `-Ino-access-permissions -Iall-good`, clang will throw an error (EACCES

[PATCH] D107049: [clang-repl] Re-implement clang-interpreter as a test case.

karies added inline comments. Comment at: clang/unittests/Interpreter/ExceptionTests/CMakeLists.txt:2 +# The interpreter can throw an exception from user input. The test binary needs +# to be compiled with exception support to expect and catch the thrown +# exception. ---

[PATCH] D32525: [clang-format] Add SpaceBeforeColon option

karies added a comment. Does this qualify? https://github.com/root-project/root/blob/master/.clang-format#L84 # You want this : enable it if you have https://reviews.llvm.org/D32525 # SpaceBeforeColon: false in ROOT's `.clang-format`. https://reviews.llvm.org/D32525 ___

[PATCH] D34985: Do not read the file to determine its name.

karies added a comment. In https://reviews.llvm.org/D34985#801498, @bruno wrote: > @v.g.vassilev will this also benefit from `ContentCache::getBuffer` > improvements from https://reviews.llvm.org/D33275? I guess if `getBuffer` > transparently handles pointing to right buffer we won't need this

[PATCH] D34985: Do not read the file to determine its name.

karies added a comment. To be clear: emitting annotations will trigger the determination of `PresumedLoc`s. As part of that (but not the first part, IIRC) `SourceManager::getBufferName(()` will be called which will trigger the `fopen` of the file, just to get its name. Another task of `Presume

[PATCH] D34912: Handle cases where the value is too large to fit into the underlying type.

karies added a comment. Two comments: - I think the part `Val.getBitWidth() == 64` likely needs rewording, although I don't know how - I can show the motivation, not sure whether that qualifies as a test case: $ echo 'template struct S{}; S<(unsigned long long)-1> s = 42;' | clang++ -fsynta

[PATCH] D34439: Add GCC's noexcept-type alias for c++1z-compat-mangling

karies added a comment. For the record, here's what GCC does (from https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html#C_002b_002b-Dialect-Options which probably has a typo, the second -Wnoexcept is likely meant to be -Wnoexcept-type): "Enabled by -Wabi and -Wc++1z-compat." -Wc+

[PATCH] D30000: Fix for pr31836 - pp_nonportable_path on absolute paths: broken delimiters

karies added inline comments. Comment at: test/Lexer/case-insensitive-include-pr31836.sh:6 +// RUN: touch %T/case-insensitive-include-pr31836.h +// RUN: echo "#include \"%T/Case-Insensitive-Include-Pr31836.h\"" | %clang_cc1 -E - 2>&1 | FileCheck %s + @twoh Does

[PATCH] D30000: Fix for pr31836 - pp_nonportable_path on absolute paths: broken delimiters

karies added inline comments. Comment at: lib/Lex/PPDirectives.cpp:1983 + isLeadingSeparator = false; +else + Path.append(Component); eric_niebler wrote: > What happens on Windows for an absolute path like "C:/hello/world.h", I > wonder