Swift 4.x (x < 2) names are obsoleted in 4.2, not 5.

[tkremenek]

In APINotes, when an unversioned name overrides a previously declared name with a Swift version, if the
previously declared name is guarded under version 4 the obsoleted version should be 4.2, not 5. In all other cases, the obsoleted version is the next major Swift version.

Fixes rdar://problem/39950937

[tkremenek]

@swift-ci test

[tkremenek]

@jrose-apple I'm not certain what to do about the else block:

        } else {
          // Future names are introduced in their future version.
          assert(getVersion() > getActiveSwiftVersion());
          attr = new (ctx) AvailableAttr(
              SourceLoc(), SourceRange(), PlatformKind::none,
              /*Message*/StringRef(), ctx.AllocateCopy(renamed.str()),
              /*Introduced*/clang::VersionTuple(majorVersion), SourceRange(),
              /*Deprecated*/clang::VersionTuple(), SourceRange(),
              /*Obsoleted*/clang::VersionTuple(), SourceRange(),
              PlatformAgnosticAvailabilityKind::SwiftVersionSpecific,
              /*Implicit*/false);
        }

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - cc3024d

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - cc3024d

[jrose-apple]

Oof, right, that makes sense. Thanks, Ted.

[jrose-apple]

I think the else-block should preserve the minor version number iff it's 4.2. Another hardcoding, but it doesn't really make the problem worse.

[tkremenek]

@swift-ci test

[tkremenek]

@jrose-apple Can you confirm my logic for the else block is what you wanted?

[tkremenek]

@swift-ci smoke test

[tkremenek]

@swift-ci smoke test

[tkremenek]

@swift-ci smoke test

[jrose-apple]

Yes, this looks fine (as far as hardcoding goes).

[tkremenek]

@swift-ci smoke test

[tkremenek]

@swift-ci smoke test