Page MenuHomePhabricator

Improve error message from FrontendAction
Changes PlannedPublic

Authored by jfb on Aug 6 2019, 10:34 PM.

Details

Reviewers
None
Summary

It's called in a few place, and for D63518 I initially set all their error propagation to ignore errors so we could propagate them one at a time. This change takes that second step and enables propagation, improving some module-related diagnostics.

Event Timeline

jfb created this revision.Aug 6 2019, 10:34 PM
Herald added a project: Restricted Project. · View Herald TranscriptAug 6 2019, 10:34 PM
jfb planned changes to this revision.Aug 6 2019, 10:37 PM

There's a failure in clang/test/Index/pch-from-libclang.c. @thakis disabled that test for all but Darwin in r352809, and with my change I now get:

Internal compiler error: LFS error for "/Users/jfb/s/llvmm/debug/tools/clang/test/Index/Output/pch-from-libclang.c.tmp.mcp/14EC4PG1UTVLY/modules.idx"failed to create unique file /Users/jfb/s/llvmm/debug/tools/clang/test/Index/Output/pch-from-libclang.c.tmp.mcp/14EC4PG1UTVLY/modules.idx.lock-0ae18733: No such file or directory

From the test, it's the result of running:

/Users/jfb/s/llvmm/debug/bin/clang -fsyntax-only -include /Users/jfb/s/llvmm/debug/tools/clang/test/Index/Output/pch-from-libclang.c.tmp.h /Users/jfb/s/llvmm/clang/test/Index/pch-from-libclang.c -Xclang -verify -fmodules -fmodules-cache-path=/Users/jfb/s/llvmm/debug/tools/clang/test/Index/Output/pch-from-libclang.c.tmp.mcp -Xclang -detailed-preprocessing-record -Xclang -triple -Xclang x86_64-apple-darwin -Xclang -fallow-pch-with-compiler-errors

@akyrtzi do you know what's going on? I haven't investigate yet, and am hoping you'll just know :)

Sorry, it's not clear to me what is the issue.

jfb added a comment.Aug 7 2019, 12:57 PM

My current guess is that this part of the test:

c-index-test -write-pch %t.h.pch %s -fmodules -fmodules-cache-path=%t.mcp -Xclang -triple -Xclang x86_64-apple-darwin

Is expected to generate the unknown type name error, but when than happens it ignores -fmodules-cache-path=%t.mcp and doesn't create the directory. The next line expects the directory to exist, which is why it can't create the lock file (because the directory it's trying to create it in doesn't exist).

In D65846#1619645, @jfb wrote:

My current guess is that this part of the test:

c-index-test -write-pch %t.h.pch %s -fmodules -fmodules-cache-path=%t.mcp -Xclang -triple -Xclang x86_64-apple-darwin

Is expected to generate the unknown type name error, but when than happens it ignores -fmodules-cache-path=%t.mcp and doesn't create the directory. The next line expects the directory to exist, which is why it can't create the lock file (because the directory it's trying to create it in doesn't exist).

clang -fmodules -fmodules-cache-path=... is supposed to create the directory for the cache path, including the parent directories, AFAIK. If this doesn't happen it is a behavior change (and undesirable IMO).

bruno added a comment.Aug 7 2019, 1:43 PM
Internal compiler error: LFS error for "/Users/jfb/s/llvmm/debug/tools/clang/test/Index/Output/pch-from-libclang.c.tmp.mcp/14EC4PG1UTVLY/modules.idx"failed to create unique file /Users/jfb/s/llvmm/debug/tools/clang/test/Index/Output/pch-from-libclang.c.tmp.mcp/14EC4PG1UTVLY/modules.idx.lock-0ae18733: No such file or directory

yay! I really like how it looks now, thanks for pushing on this.

clang -fmodules -fmodules-cache-path=... is supposed to create the directory for the cache path, including the parent directories, AFAIK. If this doesn't happen it is a behavior change (and undesirable IMO).

Is c-index-test invoking clang or do we just have a similar interface? Perhaps it's not doing it right (haven't seen this problem happening directly while invoking clang). Should -fallow-pch-with-compiler-errors be considered somehow here?

clang -fmodules -fmodules-cache-path=... is supposed to create the directory for the cache path, including the parent directories, AFAIK. If this doesn't happen it is a behavior change (and undesirable IMO).

Is c-index-test invoking clang or do we just have a similar interface? Perhaps it's not doing it right (haven't seen this problem happening directly while invoking clang). Should -fallow-pch-with-compiler-errors be considered somehow here?

To clarify, c-index-test only uses the libclang APIs. JF said "The next line expects the directory to exist", which I assume refers to the clang invocation, which is why I mention that a clang invocation does not need to expect for the cache directory to exist.
Also -fallow-pch-with-compiler-errors is always enabled by the libclang API that is used to create a PCH.