[embedded] In -assert-config Debug, print errors in assertions, preconditions, fatalErrors

[kubamracek]

This PR aims to improve how preconditions and fatalErrors are compiled in Embedded Swift:

• For "production" binaries, i.e. -O or -Osize builds:
  • Failed preconditions, preconditionFailures and fatalErrors still just emit a trap (already the case today).
  • fatalErrors will use Builtin.condfail_message instead of Builtin.int_trap to avoid collapsing multiple trap sites into one. This will get the behavior on par with failed preconditions and preconditionFailures, which already do that.
• In non-production binaries, i.e. -Onone builds or -O/-Osize builds with -assert-config Debug:
  • Failed preconditions and fatalErrors will print the file name, line number and message, just like desktop Swift does. This will have a (probably significant) codesize cost.
  • Indirectly, this will also prevent traps from collapsing into one, because the line numbers will be different.

[kubamracek]

PR is missing tests, will add them once we get agreement that this is the right approach :)

[kubamracek]

@eeckstein do you have guidance on whether relaxing this assert is reasonable, or if there's a better way to solve the following problem?

Basically the situation is: The stdlib has an @_extern(c) func putchar (without a body), which gets serialized into the stdlib. A user module also has a @_extern(c) func putchar (without a body). This then triggers this assert when we indirectly end up deserializing this forward declaration from the stdlib.

[eeckstein]

Hm, can this also happen in regular swift?
Is it possible to narrow down the case, e.g. exclude C function decls?

[kubamracek]

This is the minimal reproducer:

// RUN: %empty-directory(%t)
// RUN: %{python} %utils/split_file.py -o %t %s

// RUN: %target-swift-frontend -emit-module -o %t/MyModule.swiftmodule %t/MyModule.swift -enable-experimental-feature Embedded -parse-as-library
// RUN: %target-swift-frontend -c -I %t %t/Main.swift -enable-experimental-feature Embedded -o %t/a.o

// REQUIRES: swift_in_compiler
// REQUIRES: OS=macosx || OS=linux-gnu

// BEGIN MyModule.swift

@_extern(c)
func some_c_api()

@_transparent
public func publicFuncInAModule() {
  internalFuncInAModule()
}

@usableFromInline
internal func internalFuncInAModule() {
  some_c_api()
}

// BEGIN Main.swift

import MyModule

@_extern(c)
func some_c_api()

some_c_api()
publicFuncInAModule()

[eeckstein]

As discussed offline, it's only happening in embedded swift. It's fine to keep it as is. Just add your explanation as a short comment

[eeckstein]

See my comment about the assert. Otherwise LGTM

[eeckstein]

Hm, can this also happen in regular swift?
Is it possible to narrow down the case, e.g. exclude C function decls?

[kubamracek]

@swift-ci please test

[kubamracek]

@swift-ci please test

[kubamracek]

@swift-ci please test

[eeckstein]

lgtm!

[kubamracek]

@swift-ci please test

[kubamracek]

@swift-ci please test

[kubamracek]

@swift-ci please test