Add Embedded Swift update blog post

[rauhul]

No description provided.

[dempseyatgithub]

I had a few wording suggestions, but overall this is a very nice, informative post!

I think the added introduction paragraphs do an excellent job of giving readers a lot of information in a clear, concise way, with links to explore more. This will be useful both for folks new to Embedded Swift and those who are already using it.

[dempseyatgithub]

in 'a number of improvements we've made in the last few months'.

It's unclear who 'we' are.
Is it only the authors Doug and Rauhul?

Maybe use 'improvements the team has made'
or
'improvement the community has made'
or
'improvements made'

The lead sentence already uses the passive voice withouts citing exactly who is making Embedded Swift evolve rapidly.

[dempseyatgithub]

The '(follow the earlier link for more information).' seems a little awkward.

Possibly move the link to the parenthetical and update it to something like:

'(See documentation for full details.)'

[dempseyatgithub]

Possibly spell out what MMIO means the first time it is used, or add a phrase that makes it clear:

'The 0.1.x release of Swift MMIO, a package for memory mapped I/O, brings...'

'brings a bunch of bug fixes' feels more colloquial than the tone of the rest of the post.

Maybe 'brings many bug fixes' or 'includes many bug fixes'.

'brand new comprehensive documentation'

implies there was old comprehensive documentation

Maybe 'newly written comprehensive documentation'

[heckj]

Some wording suggestions, all inlined - mostly reducing passive voice and using more direct, second-person phrasing in some of the content. For links to external documentation at Swift Package Index, I tweaked up the URLS to use the "latest release" form to make the links have a little better "lifetime" as this post ages.

[heckj]

Suggested change

	There is a new opt-in set of warnings in the [EmbeddedRestrictions](https://docs.swift.org/compiler/documentation/diagnostics/embedded-restrictions) diagnostic group that diagnoses language constructs that aren’t available in Embedded Swift, such as uses of untyped throws or calling generic functions on existential values (follow the earlier link for more information). These diagnostics are enabled by default when building Embedded Swift, and can also be enabled in non-Embedded Swift using the compiler flag `-Wwarning EmbeddedRestrictions`.
	There is a new opt-in set of warnings in the [EmbeddedRestrictions](https://docs.swift.org/compiler/documentation/diagnostics/embedded-restrictions) diagnostic group that diagnoses language constructs that aren’t available in Embedded Swift, such as uses of untyped throws or calling generic functions on existential values.
	These diagnostics are enabled by default when building Embedded Swift, and can also be enabled in non-Embedded Swift using the compiler flag `-Wwarning EmbeddedRestrictions`.
	Read the full details at [EmbeddedRestrictions](https://docs.swift.org/compiler/documentation/diagnostics/embedded-restrictions).

[finagolfin]

Suggested change

	Embedded Swift is evolving rapidly. This post describes a number of improvements made in the last few months, covering everything from improved C interoperability to better debugging and steps toward a complete linkage model for Embedded Swift.
	Embedded Swift is evolving rapidly. This post describes a number of improvements made in the last few months, covering everything from improved C interoperability to better debugging, and steps toward a complete linkage model for Embedded Swift.

[finagolfin]

all-Swift -> "pure Swift" or "Swift-only"
can use this -> can now use these

[finagolfin]

Suggested change

	There is a new opt-in set of warnings in the [EmbeddedRestrictions](https://docs.swift.org/compiler/documentation/diagnostics/embedded-restrictions) diagnostic group that diagnoses language constructs that aren’t available in Embedded Swift, such as uses of untyped throws or calling generic functions on existential values.
	There is a new opt-in set of warnings in the [EmbeddedRestrictions](https://docs.swift.org/compiler/documentation/diagnostics/embedded-restrictions) diagnostic group that diagnoses language constructs that aren’t available in Embedded Swift, such as use of untyped throws or calling generic functions on existential values.

[finagolfin]

Suggested change

	At the same time LLDB added support for nested generic type aliases in Embedded Swift.
	At the same time, LLDB added support for nested generic type aliases in Embedded Swift.

[finagolfin]

Suggested change

	Now, LLDB is able to walk back through exception frames into the standard program frames and produce a backtrace that contains the missing frame(s).
	Now, LLDB is able to walk back through exception frames into the standard program frames and produce a backtrace that contains the missing frames.

[finagolfin]

Suggested change

	Embedded Swift uses a different compilation model from regular Swift that delays code generation to later in the compilation process. This compilation model has not been fully defined and has various practical problems. One such issue involves duplicate symbols: if you have four Embedded Swift libraries whose dependencies formed a diamond, like this:
	Embedded Swift uses a different compilation model from regular Swift, that delays code generation to later in the compilation process. This compilation model has not been fully defined and has various practical problems. One such issue involves duplicate symbols - if you have four Embedded Swift libraries whose dependencies form a diamond, like this:

[finagolfin]

Suggested change

	Then symbols from `A` that are used in both `B` and `C` would cause duplicate definition errors when linking both into `D`. The Swift compiler now emits symbols from imported modules using weak definitions, so the linker can de-duplicate them. This eliminates the need for flags like `-mergeable-symbols` and `-emit-empty-object-file` that provided partial workarounds.
	Then, symbols from `A` that are used in both `B` and `C` would cause duplicate definition errors when linking both into `D`. The Swift compiler now emits symbols from imported modules using weak definitions, so the linker can de-duplicate them. This eliminates the need for flags like `-mergeable-symbols` and `-emit-empty-object-file` that provided partial workarounds.

[finagolfin]

Suggested change

Another step along to path to formalizing the Embedded Swift linkage model is [SE-0497](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0497-definition-visibility.md), which defines a new `@export` attribute that controls how a function is visible to clients. The spelling `@export(implementation)` makes the implementation available for clients to emit, specialize, or inline, subsuming the longstanding but unofficial `@_alwaysEmitIntoClient` attribute. The spelling `@export(interface)` ensures that only the interface and *not* the definition of the function is made available to clients by emitting a callable symbol, allowing library developers to fully hide the implementation of a function even in Embedded Swift.

Another step along the path to formalizing the Embedded Swift linkage model is [SE-0497](https://github.com/swiftlang/swift-evolution/blob/main/proposals/0497-definition-visibility.md), which defines a new `@export` attribute that controls how a function is visible to clients. The spelling `@export(implementation)` makes the implementation available for clients to emit, specialize, or inline, subsuming the longstanding but unofficial `@_alwaysEmitIntoClient` attribute. The spelling `@export(interface)` ensures that only the interface and *not* the definition of the function is made available to clients by emitting a callable symbol, allowing library developers to fully hide the implementation of a function even in Embedded Swift.