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.

This pull request changes the diagnostic error thrown when a string interpolation isn't closed by a parenthesis properly (ie: let x = "g \(")

Previously, it would blurt out unterminated string literal, with these changes it'll instead throw expected ')' at end of string interpolation

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

Currently the SROA just overwrites already-existing expressions on variables. When SROA is recursively run on a data structure this leads to nonsensical expressions such as

type $*Outer, expr op_fragment:#Inner.x

instead of

type $*Outer, expr op_fragment:#Outer.inner op_fragment:#Inner.x

The (nonsensical) LLVM IR generated from this violates some assumptions in LLVM for example, if a struct has multiple members of the same type, you can end up with multiple dbg.declare intrinsics claiming to describe the same variable). As a quick fix, this patch detects this situation and drops the debug info. A proper fix shouldn't be too difficult to implement though.

rdar://99874371

This test does:

race()
print("Done!")

// CHECK: ThreadSanitizer: data race
// CHECK: Done!

We see some recent cases where the output of the test binary on iOS devices was:

Done!
==================
WARNING: ThreadSanitizer: data race
…

So apparently the TSan report output is not guaranteed to be printed before "Done!". Maybe this is because we print "Done!" on stdout and the sanitizer report on stderr?

The remaining question is: what changed that we are seeing this issue now, but not previously?

rdar://99713724

This test does:

race()
print("Done!")

// CHECK: ThreadSanitizer: data race
// CHECK: Done!

We see some recent cases where the output of the test binary on iOS devices was:

Done!
==================
WARNING: ThreadSanitizer: data race
…

So apparently the TSan report output is not guaranteed to be printed before "Done!". Maybe this is because we print "Done!" on stdout and the sanitizer report on stderr?

The remaining question is: what changed that we are seeing this issue now, but not previously?

rdar://99713724 (cherry picked from commit 35c7c4185ccc78edfcc6cc61f42361eaab25dd53)

Describe the bug Isolation checker does not raise error when actor isolated state is accesses from event handler closures.

Steps To Reproduce Steps to reproduce the behavior:

1. Compile snipped of code below:

import Foundation
import Combine

actor MyActor {
  private var state = 0
  private var subscribtion: AnyCancellable?

  func subscribe() {
    subscribtion = NotificationCenter.default.publisher(for: .NSCalendarDayChanged).sink { [self] _ in
      self.state += 1
    }
  }
}

actor MyActor2 {
  private var state = 0
  private var subscribtion: Any?

  func subscribe() {
    subscribtion = NotificationCenter.default.addObserver(forName: .NSCalendarDayChanged, object: nil, queue: nil) { [self] _ in
      self.state += 1
    }
  }
}

...

Expected behavior An closure can not be directly executed within actor context, so compiler should raise an error accessing isolated state from closure.

Screenshots If applicable, add screenshots to help explain your problem.

Environment (please fill out the following information)

• OS: MacOS 12.6
• Xcode 14.0 (14A309):

Additional context It might be due to the fact that closures in signatures are not currently marked as @Sendable and compiler assumes no context change happen compared to event subscription side which is inside actor. Maybe compiler should be less optimistic regarding @escaping closures by default or maybe there should be another compiler setting which will turn on pessimistic mode for @escaping closures treating them as @Sendable automatically.

If CompletionContextFinder fails to find a CompletionNode, skip trying to filter and add solutions to the completion callback. This prevents an assertion/crash in filterSolutionsForCodeCompletion which assumes CompletionNode is non-null (either an expression or keypath).

Resolves rdar://99966094.