[stdlib] Replace precondition with the internal _precondition

[HassanElDesouky]

Replace precondition with the internal _precondition in several files in stdlib/public/core.

cc @lorentey, @glessard

[HassanElDesouky]

@lorentey There are 4 occurrences in ArrayBuffer.swift which still uses precondition. I tried to change it, but I got an error while building the stdlib.

error: cannot convert value of type 'String' to expected argument type 'StaticString'

I tried casting the string to a static string but that didn't work. Do you have any idea why this is happening?

[lorentey]

That's because the internal assertions are (intentionally) only taking compile-time constant strings, not dynamic ones.

It looks like those ArrayBuffer preconditions serve a similar purpose as KEY_TYPE_OF_DICTIONARY_VIOLATES_HASHABLE_REQUIREMENTS for Dictionary and it probably would make sense to handle them in a similar way. (The VERY_LOUD_FUNCTION_NAME shows up in crash reports and serves as a (relatively) obvious indicator that such traps are due to a bug in the client code, not in the stdlib.)

We do want the trap message to be dynamically constructed (so that we can print the types involved) in this case, so we can't use _precondition. Instead, like Dictionary, these should use a regular condition and call out to the loudly named symbol in the failure case, and that ought to call _assertionFailure.

[lorentey]

@swift-ci test

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - 1d4f220

[glessard]

@swift-ci please test

[glessard]

@swift-ci please smoke benchmark

[swift-ci]

Performance (x86_64): -O

Regression	OLD	NEW	DELTA	RATIO
FlattenListFlatMap	4984	6721	+34.9%	0.74x (?)
ObjectiveCBridgeStubFromNSDate	6460	7070	+9.4%	0.91x (?)
Improvement	OLD	NEW	DELTA	RATIO
StringBuilder	331	305	-7.9%	1.09x (?)
StringBuilderSmallReservingCapacity	340	314	-7.6%	1.08x (?)
String.data.LargeUnicode	122	113	-7.4%	1.08x (?)

Code size: -O

Improvement	OLD	NEW	DELTA	RATIO
Phonebook.o	10151	9767	-3.8%	1.04x
RGBHistogram.o	22042	21626	-1.9%	1.02x
SortStrings.o	27523	27043	-1.7%	1.02x
SortLettersInPlace.o	8416	8272	-1.7%	1.02x
SortLargeExistentials.o	20100	19860	-1.2%	1.01x

Performance (x86_64): -Osize

Regression	OLD	NEW	DELTA	RATIO
DictionaryKeysContainsNative	26	30	+15.4%	0.87x (?)
String.data.LargeUnicode	107	116	+8.4%	0.92x (?)
NSStringConversion.Rebridge	424	458	+8.0%	0.93x (?)
Improvement	OLD	NEW	DELTA	RATIO
FlattenListFlatMap	5468	3949	-27.8%	1.38x (?)

Code size: -Osize

Improvement	OLD	NEW	DELTA	RATIO
SortLettersInPlace.o	7797	7570	-2.9%	1.03x
Phonebook.o	9249	8993	-2.8%	1.03x
SortIntPyramids.o	8953	8755	-2.2%	1.02x
RGBHistogram.o	20160	19724	-2.2%	1.02x
SortStrings.o	26996	26542	-1.7%	1.02x
StaticArray.o	12005	11807	-1.6%	1.02x
NibbleSort.o	14456	14258	-1.4%	1.01x
SortLargeExistentials.o	20807	20550	-1.2%	1.01x

Performance (x86_64): -Onone

Regression	OLD	NEW	DELTA	RATIO
ArrayAppendOptionals	1360	2300	+69.1%	0.59x (?)
StringInterpolation	11000	12600	+14.5%	0.87x (?)
SIMDRandomMask.Int8x64	20053	22227	+10.8%	0.90x
SIMDRandomMask.Int8x16	5374	5866	+9.2%	0.92x
DictionaryLiteral	7390	7970	+7.8%	0.93x (?)
Improvement	OLD	NEW	DELTA	RATIO
ObjectiveCBridgeFromNSSetAnyObjectForced	6820	6100	-10.6%	1.12x (?)
Data.append.Sequence.64kB.Count0.RE	31672	29267	-7.6%	1.08x (?)
Data.append.Sequence.64kB.Count0.RE.I	31680	29312	-7.5%	1.08x (?)
Data.init.Sequence.64kB.Count0.RE.I	31801	29433	-7.4%	1.08x (?)
Data.init.Sequence.64kB.Count0.RE	31702	29351	-7.4%	1.08x (?)
Data.append.Sequence.809B.Count0.RE	39449	36531	-7.4%	1.08x (?)
Data.init.Sequence.809B.Count0.RE.I	39697	36763	-7.4%	1.08x (?)
Data.append.Sequence.809B.Count.RE	39383	36534	-7.2%	1.08x (?)
Data.append.Sequence.809B.Count.RE.I	39367	36527	-7.2%	1.08x (?)
Data.init.Sequence.809B.Count.RE	39375	36621	-7.0%	1.08x (?)
DataAppendSequence	3928100	3658100	-6.9%	1.07x (?)
Data.init.Sequence.809B.Count0.RE	39641	36982	-6.7%	1.07x (?)

Code size: -swiftlibs

How to read the data

The tables contain differences in performance which are larger than 8% and differences in code size which are larger than 1%.

If you see any unexpected regressions, you should consider fixing the
regressions before you merge the PR.

Noise: Sometimes the performance results (not code size!) contain false
alarms. Unexpected regressions which are marked with '(?)' are probably noise.
If you see regressions which you cannot explain you can try to run the
benchmarks again. If regressions still show up, please consult with the
performance team (@eeckstein).

Hardware Overview

  Model Name: Mac Pro
  Model Identifier: MacPro6,1
  Processor Name: 12-Core Intel Xeon E5
  Processor Speed: 2.7 GHz
  Number of Processors: 1
  Total Number of Cores: 12
  L2 Cache (per Core): 256 KB
  L3 Cache: 30 MB
  Memory: 64 GB

[swift-ci]

Build failed
Swift Test Linux Platform
Git Sha - d769817

[glessard]

Here is a commit where I switched the precondition calls for branch-then-_assertionFailure.

[glessard]

The Linux test failed during testing of swift-docc; it has nothing to do with this.

[glessard]

@swift-ci Please clean test Linux platform

outdated review

[glessard]

@HassanElDesouky It looks like the change to sort worked. I suggest that we take that particular change to a follow-up PR. The rest looks like it's in good shape.

[HassanElDesouky]

@glessard That's good news! I can cherry pick the last commit in a separate PR but I'm not free today so I'll do that tomorrow, inshallah.

[HassanElDesouky]

@glessard I cherry picked the sort optimization commit and opened a new PR for it. I also removed that commit from this branch so now this PR is only responsible for replacing precondition with _precondition

[glessard]

@swift-ci please smoke test

[glessard]

@HassanElDesouky Thanks for helping with these changes!