[stdlib] Re-add withContiguousStorageIfAvailable to SubString.UTF8View

[Lukasa]

This is a second pass at the original patch, which broke an OS test. Originally added in #29094 and reverted in #29128. /cc @milseman

Due to an oversight it seems that we never added a
withContigousStorageIfAvailable implementation to SubString.UTF8View,
which meant that if you sliced a String you lost the ability to get fast
access to the backing storage. There's no good reason for this
functionality to be missing, so this patch adds it in by delegating to
the Slice implementation.

Resolves SR-11999. rdar://problem/58663804

[Lukasa]

@swift-ci please test

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - c69cadae61d44191a087136d758dcff6b4667009

[Lukasa]

Ok, I definitely need a Swift expert to help me here, because I can't decipher that failure at all. This failure seems to be pretty far away from the change I made, though I admit that that doesn't mean all that much.

[theblixguy]

I think the DebugInfo test failure is fixed by #29149, but I’m not sure about the other one.

[airspeedswift]

@swift-ci please test macOS platform

[Lukasa]

Thanks @airspeedswift. Ok, so is our conclusion that the full test suite does not catch the failure that caused us to back this out the first time @milseman?

[milseman]

The failure was here, which should build the test with the new compiler+stdlib, and run with the old stdlib. Your change should work if alwaysEmitIntoClient is working, IIUC.

[milseman]

@slavapestov would this be a correct use of alwaysEmitIntoClient?

[milseman]

Doh, I missed the fact that the test is generic (thanks @aschwaighofer). @Lukasa, can you have a concrete test and a generic one? The concrete one should always pass, but since witness tables are constructed at compile time, the generic one should only pass on bleeding-edge.

@lorentey, what would be the preferred way for Cory to differentiate between master and a shipped OS? Would that be something like:

  let hasSubstringWCSIA: Bool
  if #available(macOS 9999, iOS 9999, watchOS 9999, tvOS 9999, *) {
    hasSubstringWCSIA = true 
  } else {
    hasSubstringWCSIA = false
  }
  ... 

[Lukasa]

@swift-ci please test

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - c69cadae61d44191a087136d758dcff6b4667009

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - c69cadae61d44191a087136d758dcff6b4667009

[Lukasa]

@swift-ci please smoke test

[Lukasa]

@swift-ci please test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - e458538212e89a520c039ec6048ee087c57102eb

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - e458538212e89a520c039ec6048ee087c57102eb

[varungandhi-apple]

That test failure is non-deterministic and has been disabled for now.

@swift-ci please test

[lorentey]

@lorentey, what would be the preferred way for Cory to differentiate between master and a shipped OS? Would that be something like:

  let hasSubstringWCSIA: Bool
  if #available(macOS 9999, iOS 9999, watchOS 9999, tvOS 9999, *) {
    hasSubstringWCSIA = true 
  } else {
    hasSubstringWCSIA = false
  }
  ... 

Yeah, unfortunately the best we can do at the moment is to tie it to 9999-availability. The 9999s will get (manually) updated into actual version numbers when this reaches production compilers, which isn't exactly what we want, but we don't have a good way to test for custom-stdlib-or-recent-enough-OS yet. :-(

[lorentey]

Come to think of it -- we should just a boolean flag to the stdlib that indicates if it's a production build, and then we can implement the correct condition. (Annoyingly, #available doesn't support other clauses in the same if statement, so we'd have to do a nested check somehow.)

[swift-ci]

Build failed
Swift Test OS X Platform
Git Sha - c6dfea6

[Lukasa]

Hmm, the OSX failure here seems unrelated.

[Lukasa]

@swift-ci please test

[Lukasa]

Ok, where do we stand here now @milseman? Are we happy to try merging again?

[milseman]

Sorry I missed the notification. LGTM