[lldb] Fix an incorrect trigger of a per-module scratch context #9349
Conversation
which indirectly caused several ModuleSP shared pointers to live longer than two tests expected them to. The problem is that swift::performImportResolution() now apparently also reports syntax errors in function bodies, so I had to add a (terrible) heuristic to filter out actual module import errors. rdar://135575668
adrian-prantl
requested review from
felipepiovezan,
kastiglione,
jimingham and
augusto2112
and removed request for
JDevlieghere
|
@swift-ci test |
| std::string msg = llvm::toString(expr_diagnostics.GetAllErrors()); | ||
| if (StringRef(msg).contains(": could not build module ")) | ||
| return make_error<ModuleImportError>(msg); | ||
| return llvm::createStringError(msg); |
There was a problem hiding this comment.
nit: let's std::move(msg) here and above, since those are likely big strings.
There was a problem hiding this comment.
Is this not an optimization that Clang can do on its own?
There was a problem hiding this comment.
Nope, not in the middle of an expression. Clang will move when you have a naked return. E.g. imagine you had an Error class (which cannot be copied) instead of a string, this compiles:
return error;
but this doesn't compile:
return foo(error);
|
Thank you and Jim for investigating this! |
Good question! The fallback mechanism that caused this is a bit of an anachronism in the days of precise compiler invocations, and I'm thinking hard about removing it completely to simplify the code. |
adrian-prantl
merged commit 97e95e0
into
swiftlang:stable/20240723
which indirectly caused several ModuleSP shared pointers to live longer than two tests expected them to.
The problem is that swift::performImportResolution() now apparently also reports syntax errors in function bodies, so I had to add a (terrible) heuristic to filter out actual module import errors.
rdar://135575668