This PR contains the final work to convert the compiler to +0. There are still some tests failing, but I would like to get start performing PR testing of the branch.

This changes the python interpreter used to invoke the tests to Python3. Python2 has been EOL'ed by the Python Software Foundation. This migration enables the Swift test suite to run with Python 3 instead.

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

An initial implementation of a more resilient 2-word representation for String. It uses BridgeObject (for now) to achieve a high degree of resilience. In the future, we'll add more small string forms, establish UnsafeString, and generally rejigger String's views to be properly layered on top.

Notes:

• Self slices are currently implemented by forming _NSContiguousStrings to hold the sliced up _StringCore. This incurs overhead. Long term, we could support owned self slices, but for now it would be fruitful to try to eliminate all uses of self-slicing _StringCore from the stdlib. The most common occurrence (but by no means the only) is through _ephemeralString. Instead, for anything that can't possibly escape, we should convert to an UnsafeString, guarantee the lifetime, and slice that up.

• We cannot utilize small representations effectively until we start to wean ourselves off of _LegacyStringCore. Ideally (depending on project planning needs) we would be fully weaned off before adding small representations. We'd also like to get close to performance parity where it matters prior, to better gauge the impact of such optimizations.

• The spiritual predecessor to this effort is at https://github.com/dabrahams/swift/commits/string-recore, and while the physical implementation differs, that's a great demonstration of what we're trying to accomplish.

When generic metadata for a class is requested in the same module where the class is defined, rather than a call to the generic metadata accessor or to a variant of typeForMangledNode, a call to a new accessor--a canonical specialized generic metadata accessor--is emitted. The new function is defined schematically as follows:

    MetadataResponse `canonical specialized metadata accessor for C<K>`(MetadataRequest request) {
      (void)`canonical specialized metadata accessor for superclass(C<K>)`(::Complete)
      (void)`canonical specialized metadata accessor for generic_argument_class(C<K>, 1)`(::Complete)
      ...
      (void)`canonical specialized metadata accessor for generic_argument_class(C<K>, count)`(::Complete)
      auto *metadata = objc_opt_self(`canonical specialized metadata for C<K>`);
      return {metadata, MetadataState::Complete};
    }

To enable these new canonical specialized generic metadata accessors, metadata for generic classes is prespecialized as needed. So are the metaclasses and the corresponding rodata.

Previously, the lazy objc naming hook was registered during process execution when the first generic class metadata was instantiated. Since that instantiation may occur "before process launch" (i.e. if the generic metadata is prespecialized), the lazy naming hook is now installed at process launch.

A problem that we have to deal with when calling C++ constructors is that the ABI of a C++ constructor depends not only on the signature of the constructor but on the class on which it is defined. For example, it can be necessary to pass additional “implicit” arguments to constructors of virtual base classes.

It is therefore fundamentally not possible for SignatureExpansion (which doesn’t have access to the CXXConstructorDecl) to reliably produce the correct LLVM signature from only the type of the constructor. The approach we take is to try to get most of the way in SignatureExpansion by marking the SIL function return type with the @out attribute, representing the fact that C++ constructors take a this points to the object to be initialized.

This produces an “assumed” constructor ABI in SignatureExpansion that assumes there are no implicit arguments and that the return type of the constructor ABI is void (and indeed there is no way to represent anything else in the SIL type). If this assumed ABI doesn’t match the actual ABI, we insert a thunk in IRGen.

The thunk is marked alwaysinline, so it doesn’t incur any runtime overhead, but some compile-time overhead is required for LLVM to inline the thunk. If this turns out to be excessive, we can introduce what is essentially a peephole optimization for a full apply of a function_refthat refers to a C++ constructor and directly emit the constructor call in this case (along with any required implicit arguments) instead of calling the thunk. I’ve chosen not to tackle that in this PR though as it’s already large enough.

On some ABIs (e.g. Itanium x64), we get lucky and the ABI for a complete constructor call always matches the assumed ABI.

In addition to the core C++ constructor functionality, this PR adds some a couple of small required features:

• Conversion of thin to a Clang void type
• Handling of formal indirect results in SignatureExpansion::expandExternalSignatureTypes()

Add in small strings, plumb all APIs through, etc. There's some current performance issues, namely that small string support introduces branching and our default implementation technique involves spilling to the stack and calling _UnmanagedString methods. The first is unavoidable (although we're planning a better overall branching strategy to reduce this impact), the second is TODO.

This PR migrates instance member on type and type member on instance diagnostics handling to use the new diagnostics framework (fixes) and create more reliable and accurate diagnostics in such scenarios.

From: https://forums.swift.org/t/hacking-equatable-conformance-on-void/25975

The tests right now are kind of lackluster, what else can I be testing with this? What else can be improved upon in this implementation? Is there an edge case that I hadn't thought about?

cc: @jckarter @rjmccall

| | | |------------------|-----------------| |Previous ID | SR-381 | |Radar | None | |Original Reporter | @lhoward | |Type | New Feature | |Status | Closed | |Resolution | Done |

blocks:

• SR-377 Implement NSKeyed[Un]Archiver

relates to:

• SR-412 Linux: Cannot define C function pointer that returns metaclass

Issue Description:

This may be useful to implement NSStringFromClass()-compatible behaviour which is necessary in order to implement NSKeyedArchiver. I am using the attached workaround at the moment but obviously it is very fragile.

Implements apple/swift-evolution#904.

This is the implementation of the string interpolation rework. It is now feature-complete, but there are still a few things on my to-do list:

• ~~It's performing similarly to the current design overall, although individual benchmarks vary wildly—from 1.80x for StringInterpolationSmall to 0.59x for FloatingPointPrinting_Float_interpolated. (Some of the improvements in tests which have little to do with string interpolation are probably thanks to new overloads of String.init(describing:) I added to preserve source compatibility.) We want it to be faster than the status quo. I haven't dug deeply into this yet, and I'd like a second opinion from the CI.~~

• I'm wondering if it would be useful for DefaultStringInterpolation to become moveonly in the future, and if so, if that could be done without breaking ABI compatibility. @rjmccall, what do you think?

• There are a couple of test failures I'm not sure what to do with:

  • ~~Constraints/rdar42678836.swift was apparently added three days ago and has already had its message change twice. @slavapestov, @xedin, can we pin down what this test ought to do?~~

  • IDE/complete_at_top_level.swift fails because we don't suggest a Void function in a string interpolation. I think that comes from this line, which looks like it's intended to prevent you from completing a Void function where a value is expected, but I'm just guessing at its purpose. Can anyone clear up my confusion and help me figure out what this should be doing? (@nkcsgexi wrote this, but it was years ago.)

@swift-ci Please benchmark

cc @milseman

This is the implementation for a forthcoming proposal (see this discussion thread) that extends implicit member syntax to allow additional member accesses chained off of the base UnresolvedMemberExpr.

Resolves: rdar://problem/57295228

Describe the bug We recently encountered a slowdown in the compilation process of our app. Upon closer investigation it turned our that the culprit was an Array literal used in conjunction with the Array.max(by:) function.

To Reproduce Steps to reproduce the behavior:

1. Create the following swift file main.swift:

   public struct Foo {
       let title: String
       let description: String?
   }
   
   let a = Foo(title: "A", description: "a")
   let b = Foo(title: "B", description: "b")
   
   // 1. Compiles slowly
   if let maximum = [a, b].max(by: { $0.title.count + ($0.description?.count ?? 0) < $1.title.count + ($1.description?.count ?? 0) }) { print(maximum) }
   
   // 2. Compiles quickly
   // let ab = [a, b]
   // if let maximum = ab.max(by: { $0.title.count + ($0.description?.count ?? 0) < $1.title.count + ($1.description?.count ?? 0) }) { print(maximum) }
   

2. Compile with time swiftc main.swift and note the compilation time
3. Comment out the 1. Compiles slowly section and uncomment section 2. Compiles quickly
4. Compile with time swiftc main.swift and note the compilation time

Expected behavior Both cases compile within an equivalent timeframe.

Screenshots

Environment:

• OS: macOS 12.3
• Xcode Version: 13.0

I tried Xcode 13.0 embedded toolchain and org.swift.57202205151a toolchain. The issue was present in both.

Swift 5.7 added stronger index validation for String, so some illegal cases that previously triggered inconsistently diagnosed out of bounds accesses now result in reliable runtime errors. Similarly, attempts at applying an index originally vended by a UTF-8 string on a UTF-16 string now result in a reliable runtime error.

As is usually the case, new traps to the stdlib exposes code that contains previously undiagnosed / unreliably diagnosed coding issues.

Allow invalid code in binaries built with earlier versions of the stdlib to continue running with the 5.7 library by disabling some of the new traps based on the version of Swift the binary was built with.

In the case of an index encoding mismatch, allow transcoding of string storage regardless of the direction of the mismatch. (Previously we only allowed transcoding a UTF-8 string to UTF-16.)

rdar://93379333

Ambiguities like:

struct S {
  init(v: Int) {}
  init(v: Int, _: () -> Void) {}

  func callAsFunction(_: () -> Void) {}
}

S(v: 42) {
}

Should always be resolved in favor of choice that doesn't require injection of .callAsFunction, so let's try to avoid solving if such an overload has already been found.

Cherry-pick of https://github.com/apple/swift/pull/58950

• Explanation: any does not parse in structural types within enum associated value types. This change allows the following code to compile:

protocol P {}

enum E {
  case hello((any P) -> Void)
}

• Scope: This change simply calls into Parser::startsParameterName, which already supports looking for contextual any and some, instead of repeating the code without checking for contextual keywords in Parser::canParseTypeTupleBody.
• Risk: Low.
• Testing: Added new unit tests.
• Reviewer: @DougGregor

Resolves: rdar://93382182

Cherry-picks 862f3fc4206b19b98dbda27e6d7c258a4bcf7344 (https://github.com/apple/swift/pull/58912) which fixes async to be a contextual keyword rather than an identifier.

Resolves rdar://93080331.