This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Avoid "expected one compiler job" by picking the first eligible job.
ClosedPublic

Authored by sammccall on Aug 6 2021, 3:07 AM.

Details

Summary

This happens in createInvocationWithCommandLine but only clangd currently passes
ShouldRecoverOnErorrs (sic).

One cause of this (with correct command) is several -arch arguments for mac
multi-arch support.

Fixes https://github.com/clangd/clangd/issues/827

Diff Detail

Event Timeline

sammccall created this revision.Aug 6 2021, 3:07 AM
sammccall requested review of this revision.Aug 6 2021, 3:07 AM
Herald added projects: Restricted Project, Restricted Project. · View Herald TranscriptAug 6 2021, 3:07 AM
kadircet added inline comments.Aug 6 2021, 3:40 AM
clang-tools-extra/clangd/unittests/CompilerTests.cpp
59 ↗(On Diff #364738)

maybe move this test to clang/unittests/Frontend/ASTUnitTest.cpp? someone might send a patch to handle -arch specifically in clangd and it would no longer be possible to test this behaviour :)

(another option would be to test this through some other flags that'll trigger multiple compiler invocations, but I don't have any on top of my head)

68 ↗(On Diff #364738)

nit: --target=macho is enough. and AFAICT root reason to support multiple architectures is mach object type.

clang/lib/Frontend/CreateInvocationFromCommandLine.cpp
92

hmm, this looks like a subtle behaviour change. I definitely like the behaviour you proposed better, but maybe do it in a separate patch for making the revert easier if need be?

sammccall marked 2 inline comments as done.Aug 6 2021, 9:47 AM
sammccall added inline comments.
clang/lib/Frontend/CreateInvocationFromCommandLine.cpp
92

Which behavior change are do you mean?

When RecoverFromErrors is false and OffloadCompilation is false, behavior is same as before: if there isn't exactly one job we diagnose that and exit, if it's not suitable we diagnose that and exit.

When RecoverFromErrors is true we search for the first suitable job, instead of complaining that the number is wrong or the one at the front isn't suitable, this is the intended change (and basically only affects clangd).

When OffloadCompilation is true, there is a behavior change: previously we'd use the first job and fail if it's not clang, now we'll use the first clang job. The old behavior seems brittle and the change only affects (previously) error cases, and I'd have to add more complexity to preserve it - is this worthwhile?

sammccall updated this revision to Diff 364829.Aug 6 2021, 9:47 AM

address comments

kadircet accepted this revision.Aug 11 2021, 2:00 AM

thanks, lgtm!

clang-tools-extra/clangd/Compiler.cpp
42

not sure i follow this change. is this for making sure fatal/error diagnostic counts can be checked (so that actions can signal failure) or something else?

clang/lib/Frontend/CreateInvocationFromCommandLine.cpp
92

When OffloadCompilation is true, there is a behavior change: previously we'd use the first job and fail if it's not clang, now we'll use the first clang job.

I was talking about this particular change.

The old behavior seems brittle and the change only affects (previously) error cases

As mentioned I also like the new behaviour more, I just don't know about what the offloading logic does (i suppose it is about cuda compilation) and I was anxious about it breaking when one of the Jobs satisfy the constraint but it is not the first one.

and I'd have to add more complexity to preserve it - is this worthwhile?

One option could be to just keep this part the same (i.e. only use the first Job as long as PickFirstOfMany is set, even if OffloadCompilation is false). Then send a follow-up change, that'll search for a suitable job. That way we can only revert the last one if it breaks and know the constraints. (And decide to do the search iff ShouldRecoverOnErorrs && !Offload). But it is not that important, feel free to just land as-is.

This revision is now accepted and ready to land.Aug 11 2021, 2:00 AM
sammccall marked an inline comment as done.Aug 12 2021, 3:38 PM
sammccall added inline comments.
clang-tools-extra/clangd/Compiler.cpp
42

Oops, this was leftover from when we were testing this in clangd. (And was for the reason you suggested, just for testing). Removed.

clang/lib/Frontend/CreateInvocationFromCommandLine.cpp
92

It makes sense. I think i'm happy enough with this patch just getting reverted in such a case though, especially since it's just "defense in depth" currently rather than "load-bearing".