Is there a utility for exec'ing a command without a shell? Seems this could also be solved by avoiding a shell altogether.

thanks!

thanks for your help. As you suggested, using a #line directive and viewing the IR generated by clang, led to showing how to change the file via DILexicalBlockFile.

Test new logic in coro-async.ll

There is a second .resume.1, thanks I hadn't noticed that, I'll see if I can use that.

following up here, looks like test/Transforms/Coroutines/coro-async.ll is the test that has the right "existing testcase" however it looks like I need to duplicate the whole thing and then tweak it. That test covers the SP->getFile() == DL->getFile() case, and if I change it by "artificially changing a suspend point's !dbg location to use a different file name", then it will instead test cover the inverted case (SP->getFile() != DL->getFile()).

@thakis thanks for pointing that out. I had tried -Wall using the clang included with the latest version of Xcode, and that does not enable -Wmisleading-indentation. I see from the compiler explorer that recent clang versions do include misleading indentation diagnostics with -Wall. It seems worth keeping in until an Xcode release includes it with -Wall.

only propagate scope line when files are the same

I've updated this to follow this advice:

Change logic to be based on current scope line, not current filename.

use "accepted" as the verb

Will keep an eye on buildbots, thanks.

Didn't mean to self-accept this, so I resigned as reviewer.

Enable for llvm.

@dblaikie I have checked lldb, it builds cleanly. In the downstream swift branch of lldb there were a couple issues.

@Tyker in case you didn't see my previous message, I'm curious if you'd be willing to take a look at the bug. Thanks!

Add unittest

I changed direction, to ensure the impl pointer is always non-null.

Ensure m_impl_up is always non-null

I should expand this to fix other unchecked dereferences.

In D99825#2672670, @dblaikie wrote:

@aaron.ballman's point that maybe this should be -Werror by default in clang sounds plausible - because not all projects will be using -Werror, etc. If that helps some users who work on LLVM itself but don't want to turn on -Werror (not sure why - the buildbots will do it and so things will break/you'll have to fix stuff if you're not building with -Werror using a fairly recent clang) that's OK.

I guess wait until the dust on https://reviews.llvm.org/D101037 settles?

I like it, though I'm not sure about the python3 requirement.

other than the clang-tidy note about the capitalization of rpath, lgtm

For reformat commits, what are your thoughts on adding the shas in .git-blame-ignore-revs?

Generally we try pretty hard to be -Werror clean for clang at least (& some folks do so for gcc too)

friendly ping @jingham

1. I've updated the summary to include wording from the original diff D98224 which points out that -Werror=return-type is used in libcxx, libcxxabi, and libunwind.
2. Warnings have a spectrum of severity, -Wreturn-type is one of the most severe, but turning on -Werror for more mundane warnings would be a deal breaker for some projects. I think it's more reasonable to turn errors on individually, rather than require a codebase to be all or nothing.
3. There are already other -Werror=... in this same file, so there is precedent.

fix lldb/test/API/commands/frame/recognizer/main.m

s/lldb alias/pdb alias

Indent source block

nice fix!

🚢

@xbolva00 yes I plan to do that. I'll quickly check into the gcc situation first, and but may just re-enable it for clang.

Reverted because some versions of gcc can emit -Wreturn-type warnings on functions that have exhaustive switches over enums. A fix is to use llvm_unreachable but that's not currently done everywhere (and also seems like a poor/unnecessary practice).

Jim previously approved this offline.

thanks. I reverted my module change 736afe465f4216f55372a907d7288910f9de6bea

I pushed f1b690598eeca0568e39134f28e0a59c1c1f3598 as a fix or temporary fix.

@Tyker Hi, I noticed a case that isn't caught by -Wmisleading-indentation. In code that uses two space indents, there's a corner case that isn't caught when the preceding if uses curly braces. I've noticed a couple instances of this in lldb.