For reparenting, we rely on a default associated conformance witness accessor
to build the witness table for 'Self: NewParent' at runtime. This means that
when mangling the symbol for such a descriptor, we need support for there
being no associated type at all; it's just tau_0_0 aka Self as the subject.
This patch extends _default_ associated conformance witness accessor mangling
to support a GenericTypeParamType for the subject, as the non-default accessors
already quietly did have support; see `mangleAssociatedConformanceDescriptor`.
It was quiet in the sense that there was no demangling support for it, nor
documentation about it either. So I've brought both kinds of witness accessor
manglings up-to-par, without extending the `assoc-type-name` grammar itself.
These two new invariants eliminate corner cases which caused bugs if optimization didn't handle them.
Also, it will significantly simplify lifetime completion.
The implementation basically consists of these changes:
* add a flag in SILFunction which tells optimization if they need to take care of infinite loops
* add a utility to break infinite loops
* let all optimizations remove unreachable blocks and break infinite loops if necessary
* add verification to check the new SIL invariants
The new `breakIfniniteLoops` utility breaks infinite loops in the control flow by inserting an "artificial" loop exit to a new dead-end block with an `unreachable`.
It inserts a `cond_br` with a `builtin "infinite_loop_true_condition"`:
```
bb0:
br bb1
bb1:
br bb1 // back-end branch
```
->
```
bb0:
br bb1
bb1:
%1 = builtin "infinite_loop_true_condition"() // always true, but the compiler doesn't know
cond_br %1, bb2, bb3
bb2: // new back-end block
br bb1
bb3: // new dead-end block
unreachable
```
The option can be used to save the SIL after optimizations to a file.
In contrast to `-emit-sil`, the compiler doesn't stop an continues to e.g. create the regular output object file
This experimental feature allows you to override the default behavior
of a 'get' returning a noncopyable type, so that it returns an owned
value rather than a borrow, when that getter is exposed in opaque
interfaces like protocol requirements or resilient types.
resolves rdar://157318147
This does not rename all the internal variables, functions, and types
whose names were based on the old syntax.
I think it adds new syntax support everywhere it's needed while
retaining enough of the old syntax support that early adopters will
see nice deprecation messages guiding them to the new syntax.
Just had to do this recently and realized I had forgotten how to do it. Placing
it in DebuggingTheCompiler.md so I can look it up from here again after I forget
how to do it again.
Freshly built libc++ introduces issues when building `swift-build`:
```
Undefined symbols for architecture arm64:
"std::__1::__hash_memory(void const*, unsigned long)", referenced from:
(anonymous namespace)::CAPIBuildDB::buildUpKeyCache(std::__1::vector<llbuild::core::KeyType, std::__1::allocator<llbuild::core::KeyType>>&) in BuildDB-C-API.cpp.o
_llb_build_key_make in BuildKey-C-API.cpp.o
_llb_build_key_make_command in BuildKey-C-API.cpp.o
_llb_build_key_make_custom_task in BuildKey-C-API.cpp.o
_llb_build_key_make_custom_task_with_data in BuildKey-C-API.cpp.o
_llb_build_key_make_directory_contents in BuildKey-C-API.cpp.o
_llb_build_key_make_filtered_directory_contents in BuildKey-C-API.cpp.o
...
ld: symbol(s) not found for architecture arm64
```
<!--
If this pull request is targeting a release branch, please fill out the
following form:
https://github.com/swiftlang/.github/blob/main/PULL_REQUEST_TEMPLATE/release.md?plain=1
Otherwise, replace this comment with a description of your changes and
rationale. Provide links to external references/discussions if
appropriate.
If this pull request resolves any GitHub issues, link them like so:
Resolves <link to issue>, resolves <link to another issue>.
For more information about linking a pull request to an issue, see:
https://docs.github.com/issues/tracking-your-work-with-issues/linking-a-pull-request-to-an-issue
-->
<!--
Before merging this pull request, you must run the Swift continuous
integration tests.
For information about triggering CI builds via @swift-ci, see:
https://github.com/apple/swift/blob/main/docs/ContinuousIntegration.md#swift-ci
Thank you for your contribution to Swift!
-->
We need special handling for protocols whose requirement
signature exists but is in a serialized state, as we
cannot run the StructuralRequirementsRequest on such
a protocol as there's no work to be done, effectively.
I am adding this since I had to go spelunking around to find the SIMCTL_CHILD_
prefix which I need to debug an app. Rather than just forgetting it again, I
thought it made sense to just document it here so I can forget it again. I also
put in a little bit of other stuff about simctl as well while I was here.
I took down my medium.com blog a few years ago, and all of the same material
in this post is now found in "Compiling Swift Generics", in docs/Generics/.
