[stdlib] Add a version number for the stdlib itself; use it in unit tests

[lorentey]

The usual OS-based availability checks aren't always appropriate -- the stdlib we're actually using may not correspond to the version that shipped with the OS we're running on. This makes it tricky to decide whether a particular fix is supposed to be present in the current stdlib, which is a problem for unit tests that are supposed to test these changes.

Add an (arbitrary) version number for the stdlib itself, and use it to skip certain tests that are checking for behavioral changes introduced in 5.1.

rdar://problem/50150948

[lorentey]

@swift-ci please test

[lorentey]

These version numbers would form a progression like this:

                master:  (1024, 0) → (1025, 0) → (1026, 0) → (1027, 0) → ...
swift-<version>-branch:              (1025, 0) → (1025, 1) → (1025, 2) → ...

We would need to bump the version whenever we introduce a behavioral change that we want to be able to reliably test.

In this setup, versions corresponding to actual toolchain releases would be whatever the version was on the tag the toolchain was built from: say, (1025, 24) or (1329, 128).

These values would explicitly not correspond to major/minor/patch version numbers in some semantic versioning scheme.

Points to ponder:

• Instead of such versioning, would it be enough to know if the current stdlib was loaded from /usr/lib/swift or a custom toolchain build?

  • I suspect it would, but it could be challenging to ensure we get the logic right every time.

• How often will this cause merge conflicts?

  • Cherry picking to release branches will be more annoying, and PRs will conflict more often.

  • We should make sure routine version bumps never lead to automerger failures -- the version must be kept in sync between branches that use change propagation.

• Do we keep tests indefinitely gated at random .custom(2312, 13) version numbers, or do we go back and update them to the released version once that's done?

  • How do we maintain the mapping between official releases and these versions?

• Should we rather implement a proper semantic versioning scheme?

• Is there a way to tie the availability of stdlib's own features to these finer-grained versions, rather than magical 9999 OS versions?

[lorentey]

@swift-ci please test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 71f57d3

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - 71f57d3

[milseman]

I still don't see why we need to back-deploy or bake any implementation details into our ABI.

[milseman]

Why do we want back-deployment?

[lorentey]

Is there a reason we shouldn't? I expect to always be able to retrieve a version number; tying it to an explicit availability check would reduce its usefulness.

[milseman]

Not needed if not back deploying

[milseman]

Still a little confused. Why is this public?

[lorentey]

It allows tests to easily determine if they are back/forward deployed. Binaries that are intimately tied to a particular revision of the stdlib and should not be separately back/forward deployed (e.g. libswiftFoundation) could use it for sanity checks.

if _stdlibDynamicVersion < _stdlibStaticVersion {
  print("I'm back-deployed")
}

This is not strictly necessary, but it seems like a cheap addition. If it's available, the "current" version need not be duplicated (and updated) in more than one place.

[lorentey]

FWIW, dyld provides two similar version numbers through NSVersionOfRunTimeLibrary and NSVersionOfLinkTimeLibrary.

(The link-time version queries the linkage of the main executable, not the current object, so it's different(ly useful) than the static version number implemented here.)

[milseman]

@lorentey and I discussed this. If this is just used for our own testing, we can keep it internal so long as StdlibUnittest is built with disable access control.

Karoy, what do you think about making this proper API at some point?

[lorentey]

Closing; adding 9999 availability guards to such behavioral tests already covers the most important deployment scenarios. (#24496) A version number like this would be helpful, but its maintenance cost would exceed its usefulness in its current form. (E.g., this variant does not plug into @available syntax.)

[lorentey]

@milseman I think all resilient Swift modules should have their own separate version number, and there should be a standard way to access it (both at compile-time and at runtime). The version number should be usable in compile-time @available declarations and runtime #available checks. Also, the version number should match the one used by SPM, which implies a semantic versioning scheme.