Strip the use of `env` on Windows which will swallow the error code if
the GnuWin32 version (which is recommended/used by LLVM) is used. Since
SDKROOT should not be set on Windows anyways, this should not matter
much in practice but will help improve the test coverage on Windows.
Additionally, remove the path lowercasing on Windows as the path is kept
in the proper case, even on the nightlies. This should help improve the
number of Driver tests that pass.
With this change, I now can get all the Driver tests to pass locally.
Fix several problems with FixedPointConversion generation code.
The first problem is that at some point `repr(value)` was being used,
which turn the number into a string. That was great for printing the
number, but make the test against the value of the number (like
`testValue < otherMin` always false. There were a number of tests that
were never performed, specifically the integer tests.
The second problem was using doubles in the Python code. For Float32 and
Float64 the tests were generated correctly, but in the case of Float80,
the test adding or removing a quantity to the maximum/minimum were
failing because of the lack of precission (Adding 0.1 to a very
big/small number is the same as not adding anything). Switching to
Decimal should keep enough precission for the tests.
Finally the last problem was that the bounds of the conversions are not
actually `selfMin` and `selfMax`, but the values returned by the utility
function `getFtoIBounds`. For example for unsigned types, the lower
bound is always -1, not zero (every value between -1 and zero is rounded
to zero, and doesn't fail).
Instead of using nested gyb templates, use lit.cfg %target-ptrsize,
which should be faster, cleaner, and provides correct line-directive
output.
Remove a bunch of warnings in Swift when compiling the generated result
of FixedPointConversion.swift.gyb.
Co-authored-by: Gwynne Raskind <gwynne@users.noreply.github.com>
Before extending TupleShuffleExpr to represent all tuple
conversions allowed by the constraint solver, remove the
parts of TupleShuffleExpr that are no longer needed; this is
support for default arguments, varargs, and scalar-to-tuple and
tuple-to-scalar conversions.
Right now we use TupleShuffleExpr for two completely different things:
- Tuple conversions, where elements can be re-ordered and labels can be
introduced/eliminated
- Complex argument lists, involving default arguments or varargs
The first case does not allow default arguments or varargs, and the
second case does not allow re-ordering or introduction/elimination
of labels. Furthermore, the first case has a representation limitation
that prevents us from expressing tuple conversions that change the
type of tuple elements.
For all these reasons, it is better if we use two separate Expr kinds
for these purposes. For now, just make an identical copy of
TupleShuffleExpr and call it ArgumentShuffleExpr. In CSApply, use
ArgumentShuffleExpr when forming the arguments to a call, and keep
using TupleShuffleExpr for tuple conversions. Each usage of
TupleShuffleExpr has been audited to see if it should instead look at
ArgumentShuffleExpr.
In sequent commits I plan on redesigning TupleShuffleExpr to correctly
represent all tuple conversions without any unnecessary baggage.
Longer term, we actually want to change the representation of CallExpr
to directly store an argument list; then instead of a single child
expression that must be a ParenExpr, TupleExpr or ArgumentShuffleExpr,
all CallExprs will have a uniform representation and ArgumentShuffleExpr
will go away altogether. This should reduce memory usage and radically
simplify parts of SILGen.
I recently enabled TSan interceptors for libdispatch on non-Apple
platforms in upstream. This is on by default on Apple platforms. Let's
try to switch it on for other platforms too.
This reapplies four commits for the ClangImporter. They broke the build
on master because the associated commits on swift-clang's
swift-5.1-branch never made it to stable due to automerger woes. This
time I'll push everything through manually.
These are the commits being reapplied:
- a42bc62397 "ClangImporter: Share a module cache between CompilerInstances"
- 9eed34235b "ClangImporter: Adjust to r355777, PCMCache => ModuleCache"
- da8a1c57e8 "ClangImporter: Use the new CacheGeneratedPCH in Clang"
- 2134b17a20 "ClangImporter: Test that PCHs are actually cached in memory"
rdar://problem/48545366
Use an APInt to create the spare bit mask for integer values. This
will allow us to byte swap it when we make the SpareBitVector
strictly little-endian even when targeting big-endian machine.
While editing this code I've also got rid of the goto statement
since it seemed unnecessary.
* [typechecker] fix an issue with redeclaration checking
* [typechecker] use mapSignatureFunctionType in getOverloadSignatureType() to compute the type for the enum element decl, etc
* [typechecker] allow matching enums to functions as well, not just functions to enums
* [typechecker] fix the check for two enums
* [typechecker] check for nominal types as well when comparing enum elements
* [test] add more tests
* [typechecker] check for typealias as well
Based on the same concept of swift-api-dump, this python wrapper
provides framework authors a convenient way to generate baseline or
diagnose ABI/API breakages from an existing toolchain where it has
swift-api-digester installed.
cmake installation part will be added in a separate PR.
rdar://problem/29649661
We already detected when a typealias /changed/ incompatibly; being
unable to deserialize it at all is just a very dramatic version of
that, right?
https://bugs.swift.org/browse/SR-9811
There should be escaped identifiers in code completion:
- As primary expression: Any keyword name except for `self` and `Self`.
- After dot: Something named `init`.
rdar://problem/16232627
Reuse AccessStorageAnalysis to summarize accesses.
Don't ignore call sites in loops.
Don't consider a read access in a loop to conflict with a read
outside.
Use the unidentified access flag from the analysis.
Remove extraneous code, some of which was unreachable.
General cleanup.
If a make_mutable operation is done conditionally in a loop, the hoisting of this operation can cause an over-release of the array buffer in some cases.
rdar://problem/48906146
