That way, when the request gets truncated by os_log in sourcekit-lsp, we see most of the request. Most likely the sourcetext and the compiler args wouldn't have made it into the log message completely anyway.
rdar://121322828
Out of all operating systems ever supported by Swift, only Ubuntu 14.04
had libstdc++ 4.8, and Swift has sunset support for Ubuntu 14.04 for a
while now.
The standard library has two versions of the `abs(_:)` function:
```
func abs<T : SignedNumeric>(_ x: T) -> T where T.Magnitude == T
func abs<T : SignedNumeric & Comparable>(_ x: T) -> T
```
The first is more specialized than the second because `T.Magnitude` is
known to conform to `Comparable`. Indeed, it’s a more specialized
implementation that returns `magnitude`.
However, this overload behaves oddly: in the expression `abs(-8)`, the type
checker will pick the first overload because it is more specialized. That’s
a general guiding principle for overloading: pick the most specialized
overload that works.
However, to select that overload, it needs to pick a type for the literal
“8” for which that overload works, and it chooses `Double`. The “obvious”
answer, `Int`, doesn’t work because `Int.Magnitude == UInt`.
There is a conflict between the two rules, here: we prefer more-specialized
overloads (but we’ll fall back to less-specialized if those don’t work) and we prefer to use `Int` for integer literals (but we’ll fall back to `Double` if it doesn’t work). We have a few options from a type-checker
perspective:
1. Consider the more-specialized-function rule to be more important
2. Consider the integer-literals-prefer-`Int` rule to be more important
3. Call the result ambiguous and make the user annotate it
The type checker currently does #1, although at some point in the past it
did #2. Moving forward, #1 is a better choice because it prunes the number
of overloads that need to be considered: if the more-specialized overload
succeeds its type-check, the others need not be considered. It’s also
easier to reason about than the literal-scoring approach, because there can
be a direct definition for “more specialized than” that can be reasoned
about.
I think we should dodge the issue by removing the more-specialized version
of `abs(_:)`. Its use of `magnitude` seems unlikely to provide a
significant performance benefit, and the presence of overloading either
forces us to consider both overloads always (which is bad for type checker
performance) or accept the regression that `abs(-8)` is `Double`. Better
to eliminate the overloading and, if needed in the future, find a better
way to introduce the more-specialized implementation without it being a
separate signature.
Fixes rdar://problem/42345366.
* Make FloatingPoint require that Self.Magnitude == Self
We didn't have the where clause to express this constraint at the time that the FloatingPoint protocol was implemented, but we do now. This is not a semantic change to FloatingPoint, which has always bound IEEE-754 arithmetic types, for which this constraint would necessarily hold, but it does effect the type system.
For example, currently the following function does not type check:
~~~~
func foo<T>(x: T) -> T where T: FloatingPoint {
var r = x.remainder(dividingBy: 1)
return r.magnitude
}
~~~~
with this change, it compiles correctly.
Having done this, we no longer need to have a separate `abs` defined on FloatingPoint; we can use the existing function defined on `SignedNumeric` instead. Additionally mark the global `fabs` defined in the platform C module deprecated in favor of the Swift `abs`; we don't need to carry two names for this function going forward.
We don't care what the USRs are here, we were just using them to avoid
results slipping in between the start of the structure and the module
name. This patch does that in a way that doesn't use the USR.
There was a ton of complicated logic here to work around
two problems:
- Same-type constraints were not represented properly in
RequirementReprs, requiring us to store them in strong form
and parse them out when printing type interfaces.
- The TypeBase::getAllGenericArgs() method did not do the
right thing for members of protocols and protocol extensions,
and so instead of simple calls to Type::subst(), we had
an elaborate 'ArchetypeTransformer' abstraction repeated
in two places.
Rewrite this code to use GenericSignatures and
GenericFunctionType instead of old-school GenericParamLists
and PolymorphicFunctionType.
This changes the code completion and AST printer output
slightly. A few of the changes are actually fixes for cases
where the old code didn't handle substitutions properly.
A few others are subjective, for example a generic parameter
list of the form <T : Proto> now prints as <T where T : Proto>.
We can add heuristics to make the output whatever we want
here; the important thing is that now we're using modern
abstractions.
* A bunch of them require objc_interop because they import code containing
Objective-C.
* Many others fail on Ubuntu 14.04 because the C++ there doesn't have a
functional std::regex implementation which is required by the
`complete-test` tool.
It may be possible to adjust some of these tests in the future to not
need these extra requirements, but this is a straightforward way to
clean up Linux test results for now.
The internal parameter names are just there to give an extra hint in the
source text for what the argument is. Consequently, we don't want to
allow filtering to match against them.
The code goes into its own sub-tree under 'tools' but tests go under 'test',
so that running 'check-swift' will also run all the SourceKit tests.
SourceKit is disabled on non-darwin platforms.
