Revert "Update for new rules on @inline(__always) function bodies"

[parkera]

Reverts #772

[slavapestov]

Why was this reverted?

[parkera]

All changes require our code review, and I don't know what the purpose of this change is. I'm going to revert it from the Darwin version soon too.

[slavapestov]

This change should have no effect on generated code.

Marking a property as @_versioned has the effect of giving its accessors public linkage. However stored properties are accessed directly where possible anyway. What’s changing is that now the compiler is enforcing rules about references to private and internal entities from inlineable function bodies. To give us implementation flexibility in the future, stored properties are subject to these rules also.

Previously, we did not enforce any of these restrictions in the type checker. Instead we would just fail in the SIL optimizer or linker if something was referenced that should not be. Once I merge a work-in-progress PR, Sema will start reporting diagnostics so we'll need this change to get Foundation to compile.

So more details on the rules:

• "publicly exported” means ‘public or internal but with @_versioned attribute’. The @_versioned attribute allows you to mark a declaration as having public linkage, but still not visible for direct name lookup - so its ABI but not API. This allows it to be referenced from inlineable function bodies.

• an "inlineable function body" is a publicly exported function marked @_transparent, @_inlineable or @inline(__always), or a closure nested inside such a function.

• in Swift 4 mode, default argument expressions are also inlineable, which means they’ll always be emitted into the caller of the function. Recall that in Swift 3, default argument expressions are emitted as functions in the defining module.

• non-public inlineable entities are not subject to any of these restrictions — they can only be inlined inside the module itself, since they’re not externally-visible.

One thing I’m unsure about is whether you interpreted @inline(__always) as “always inline inside this module” or “always inline into client code”. If the former, we’ll need to split off @_inlineable (which just marks a function for SIL serialization) from @inline(__always) but I’d rather not complicate the model further. You can always simulate "inline always in this module only" by putting the function body inside an internal (and not @_versioned) function marked @inline(__always).

Right now you’re also using multiple-frontend mode to compile Foundation so serialized SIL is lost and clients cannot inline it. I’ll have this fixed shortly.

Let me know if you have any other questions,

[parkera]

Thanks for the detailed explanation. The @inline(__always) here is intended to always inline into client code. Things like getting the count of a Data should be about as fast as getting the count of Array. We made some dramatic perf improvements in Data recently by using inlining and creating a Swift-native version of the logic. I wanted to make sure that work and benefits were preserved.