Skip to content

Merge bastille into main #1917

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 11 commits into from
Oct 8, 2020
Merged

Merge bastille into main #1917

merged 11 commits into from
Oct 8, 2020

Conversation

JDevlieghere
Copy link

No description provided.

jimingham and others added 11 commits October 5, 2020 15:53
…ScriptInterpreter.""

This reverts commit f775fe5.

I fixed a return type error in the original patch that was causing a test failure.
Also added a REQUIRES: python to the shell test so we'll skip this for
people who build lldb w/o Python.
Also added another test for the error printing.

(cherry picked from commit 1b1d981)
This was looking at the privateState, but it's possible that
the actual process has started up and then stopped again by the
time we get to the check, which would lead us to get out of running
the stop hooks too early.

Instead we need to track the intention of the stop hooks directly.

Differential Revision: https://reviews.llvm.org/D88753

(cherry picked from commit be66987)
This changes the logic in GetXcodeSDK to find an SDK with xcrun. The
code now executes the following steps:

 1. If DEVELOPER_DIR is set in the environment, it invokes xcrun with
    the given developer dir. If this fails we stop and don't fall back.
 2. If the shlib dir is set and exists,it invokes xcrun with the
    developer dir corresponding to the shlib dir. If this fails we fall
    back to 3.
 3. We run xcrun without a developer dir.

The new behavior introduced in this patch is that we fall back to
running xcrun without a developer dir if running it based on the shlib
dir failed.

A situation where this matters is when you're running lldb from an Xcode
that has no SDKs and that is not xcode-selected. Based on lldb's shlib
dir pointing into this Xcode installation, it will do an xcrun with the
developer set to the Xcode without any SDKs which will fail. With this
patch, when that happens, we'll fall back to trying the xcode-selected
Xcode by running xcrun without a developer dir.

Differential revision: https://reviews.llvm.org/D88866

(cherry picked from commit e3b0414)
…96a1fcfb2821ad643b0731880

[lldb] Change the xcrun (fallback) logic in GetXcodeSDK
A lot of our code building with clang-cl.exe using Clang 11 was failing with
the following 2 type of errors:

1. explicit specialization of 'foo' after instantiation
2. no matching function for call to 'bar'

Note that we also use -fdelayed-template-parsing in our builds.

I tried pretty hard to get a small repro for these failures, but couldn't. So
there is some subtle edge case in the -fpch-instantiate-templates feature
introduced by this change: https://reviews.llvm.org/D69585

When I tried turning this off using -fno-pch-instantiate-templates, builds
would silently fail with the same error without any indication that
-fno-pch-instantiate-templates was being ignored by the compiler. Then I
realized this "no" option wasn't actually working when I ran Clang under a
debugger.

Differential revision: https://reviews.llvm.org/D88680

(cherry picked from commit 66e4f07)
Tail duplication of a block with an INLINEASM_BR may result in a PHI
node on the indirect branch. This is okay, but it also introduces a copy
for that PHI node *after* the INLINEASM_BR, which is not okay.

See: ClangBuiltLinux/linux#1125

Differential Revision: https://reviews.llvm.org/D88823

(cherry picked from commit d2c61d2)
@JDevlieghere
Copy link
Author

@swift-ci please test

@fredriss fredriss merged commit 0bb10e4 into swift/main Oct 8, 2020
@JDevlieghere JDevlieghere deleted the merge-bastille-into-main branch October 8, 2020 02:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants