This overload is disfavored to make sure that it's only used for cases
that don't involve literals, for that `==(StringRef, StaticString) -> Bool`
is preferred. Otherwise these overloads are going to be ambiguous
because both `StringRef`, `StaticString` conform to `ExpressibleByStringLiteral`.
Consider the following example:
```swift
func test(lhs: StringRef) {
lhs == "<<test>>"
}
```
The type-checker used to pick `==(StringRef, StringRef)` overload in this
case because it has homogenous parameter types but this is no longer the
case because this behavior was too aggressive and led to sub-optimal choices
by completely skipping other viable overloads.
Since `StaticString` already represents literals it's better to use
a standard library type and reserve the `(StringRef, StringRef)`
overload to when the literals are not involved.
Resolves: rdar://154719565
Remove the default constructor footgun present with
the struct implementations, and sprinkle some
`SWIFT_NAME` and bridging utilities to make them
nicer to work with.
Introduce two modes of bridging:
* inline mode: this is basically how it worked so far. Using full C++ interop which allows bridging functions to be inlined.
* pure mode: bridging functions are not inlined but compiled in a cpp file. This allows to reduce the C++ interop requirements to a minimum. No std/llvm/swift headers are imported.
This change requires a major refactoring of bridging sources. The implementation of bridging functions go to two separate files: SILBridgingImpl.h and OptimizerBridgingImpl.h.
Depending on the mode, those files are either included in the corresponding header files (inline mode), or included in the c++ file (pure mode).
The mode can be selected with the BRIDGING_MODE cmake variable. By default it is set to the inline mode (= existing behavior). The pure mode is only selected in certain configurations to work around C++ interop issues:
* In debug builds, to workaround a problem with LLDB's `po` command (rdar://115770255).
* On windows to workaround a build problem.
Looking at the SIL I came to the conclusion that `Unmanaged` ins fundamentally broken.
It's easier to directly bitcast between bridged and native SIL objects. It also produces simpler SIL which can be further optimized
Let's lldb's `po` command not print any "internal" properties of the conforming type.
This is useful if the `description` already contains all the information of a type instance.
For two reasons:
* We also like to check for assert failures in release builds. Although this could be achieved with `precondition`, it's easy to forget about it and use `assert` instead.
* We need to see the error message in crashlogs of release builds. This is even not the case for `precondition`.
Also, re-export the "Basic" module in "SIL" so that the new assert implementation is also available in the Optimizer module (where all files import SIL).
This fixes a dangling pointer issue when creating a `Swift.String` from `std::string`.
Also fixes a warning:
```
warning: variable 's' was never mutated; consider changing to 'let' constant
var s = SILBasicBlock_debugDescription(bridged)
~~~ ^
let
```
rdar://92963081
rdar://93053488
and introduce the StringRef struct.
It's more efficient.
Also, rename the `HasName` protocol to `HasShortDescription`, which introduces the new requirement `shortDescription`. This is need because `name` now has `StringRef` type and not `String` anymore
