Skip to content

Swift linux cherry picks #91

New issue

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

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

Already on GitHub? # to your account

Closed
wants to merge 10,000 commits into from
Closed

Conversation

yln
Copy link
Collaborator

@yln yln commented Jan 9, 2020

rdar://58454007

git apple-llvm automerger added 30 commits December 30, 2019 14:35
git apple-llvm automerger and others added 22 commits January 3, 2020 10:30
Conflicts:
	clang/lib/Driver/ToolChains/Arch/AArch64.cpp
	llvm/include/llvm/Support/AArch64TargetParser.def
	llvm/lib/Target/AArch64/AArch64.td
	llvm/lib/Target/AArch64/AArch64Subtarget.cpp
	llvm/unittests/Support/TargetParserTest.cpp
Upstream macCatalyst driver support
Summary:
Take `struct Z {...}` defined differently and imported from both modules
X and Y. While in C/ObjC mode, clang used to pick one of the definitions
and ignore the other even though they might not be structurally
equivalent.

- Instead of using the structural equivalence code for checking
compatibility, use the ODR hash mechanism. This should significantly
speed up the checks.
- Hook the necessary name lookup bits to allow this logic in C.
- Teach diagnoseOdrViolations to check the differences.

Instead of silently compiling, clang now emits:

In module 'Y' imported from t.m:2:
./y.h:3:10: error: 'Z::m' from module 'Y' is not present in definition
of 'struct Z' in module 'X'
  double m;
         ^
./x.h:3:7: note: declaration of 'm' does not match
  int m;
      ^

rdar://problem/56764293

Reviewers: rsmith, arphaman, vsapsai, martong, jdoerfert

Subscribers: rnkovacs, jkorous, dexonsmith, ributzka, cfe-commits

Tags: #clang

Differential Revision: https://reviews.llvm.org/D71734
The current SWIG extensions for the string conversion operator is Python
specific because it uses the PythonObjects. This means that the code
cannot be reused for other SWIG supported languages such as Lua.

This reimplements the extensions in a more generic way that can be
reused.

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

(cherry picked from commit 0341c11)
The current SWIG extensions for the string conversion operator is Python
specific because it uses the PythonObjects. This means that the code
cannot be reused for other SWIG supported languages such as Lua.

This reimplements the extensions in a more generic way that can be
reused. It uses a SWIG macro to reduce code duplication.

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

(cherry picked from commit ae47a3d)
The current SWIG extensions for the string conversion operator is Python
specific because it uses the PythonObjects. This means that the code
cannot be reused for other SWIG supported languages such as Lua.

This reimplements the extensions in a more generic way that can be
reused. It uses a SWIG macro to reduce code duplication.

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

(cherry picked from commit 51bdd98)
Making the string conversion operator a macro unintentionally dropped
the backslash before '\n' and '\r' and was therefore incorrectly
stripping 'n' and 'r' from the object description.

(cherry picked from commit 93a1e9c)
All the code required to generate the language bindings for Python and
Lua lives under scripts, even though the majority of this code aren't
scripts at all, and surrounded by scripts that are totally unrelated.

I've reorganized these files and moved everything related to the
language bindings into a new top-level directory named bindings. This
makes the corresponding files self contained and much more discoverable.

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

(cherry picked from commit 6498aff)
When moving the Python directory I renamed it to python (lowercase) but
didn't update the python.swig file.

(cherry picked from commit 5e0bf67)
The Python directory for the script interpreter is still capitalized.

(cherry picked from commit 7bbd407)
…e-tag-types

[Modules] Handle tag types and complain about bad merges in C/Objective-C mode
[macOS] fix a refactor test by adjusting for AST changes
My initial implementation of `ignore_noninstrumented_modules` for Linux
(landed in 6159242) did not consider
that the GNU symbol table could be present but empty.  "Empty" means:
void of real symbol entries, but potential "terminator/placeholder"
symbols that are skipped via `header->symoffset`.  In this case
`last_symbol` is zero and we should avoid computing
`chains[last_symbol - header->symoffset]`.

This bug seems to only manifest in combination with `LD_PRELOAD`
(counterpart of `DYLD_INSERT_LIBRARIES` for Linux) and for small
binaries, (e.g., the "not" utility from the llvm test suite) that have
segments without any real symbols.

This should fix the remaining failing ASan tests on the Swift Linux CI.

rdar://57566645
(cherry picked from commit 2fb2445)
For Swift, we turn on `ignore_noninstrumented_modules` and
`ignore_interceptors_accesses` even on Linux (where they are usually
disabled).  We have to account for that when running LLVM-Swift on
Linux.

rdar://57436887
(cherry picked from commit eb6441c)
@repo-lockdown
Copy link

repo-lockdown bot commented Jan 9, 2020

This repository does not accept pull requests. Please follow http://llvm.org/docs/Contributing.html#how-to-submit-a-patch for contribution to LLVM.

@repo-lockdown repo-lockdown bot closed this Jan 9, 2020
@repo-lockdown repo-lockdown bot locked and limited conversation to collaborators Jan 9, 2020
@yln yln deleted the swift-linux-cherry-picks branch January 9, 2020 23:17
@yln yln restored the swift-linux-cherry-picks branch January 9, 2020 23:17
@yln yln deleted the swift-linux-cherry-picks branch January 10, 2020 01:03
jpinot pushed a commit to jpinot/llvm-project that referenced this pull request Apr 9, 2025
# for free to subscribe to this conversation on GitHub. Already have an account? #.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants