For the options that specifies the output, it should be cache invariant.
Fix the one remaining option that is not correctly labelled and add an
unittest to make sure all the options with output path naming convertion
are correctly marked as CacheInvariant.
rdar://146155049
This is something that I have wanted to add for a while and have never had the
need to. I need it now to fix a bug in the bots where I am forced to use IRGen
output to test ThunkLowering which causes platform level differences to show up
in the FileCheck output. With this, I can just emit the actual lowered SIL
output and just test it at that level. There are other cases like this where we
are unable to test lowered SIL so we use IRGen creating this brittleness.
Hopefully this stops this problem from showing up in the future.
rdar://138845396
Add a new filetype for this mode option: "Raw LLVM IR". When the mode
option is emit-irgen, the new filetype will be the output kind;
conversely when determining the mode option to use, if the output kind
is the new filetype, the mode option will be emit-irgen.
Make sure block-list file is read through VFS so CASFS can be used to
read the configuration to ensure sound caching, and also the path of the
blocklist can be canonicalized via path remapping.
These tests were relying on specifics of `getUniqueID` that aren't
necessarily true - namely that moving a file from `source` to `dest`
doesn't change the returned ID. They are really just testing
`moveFileIfDifferent`, which doesn't need to make this assumption.
`OpaqueReturnTypeParent` node now references the parent with a mangled parent name, rather than a parent pointer. This makes trees obtained from different demanglers (or calls to `Demangler::demangleSymbol`) for the same symbol equal.
I hit this in https://github.com/apple/swift/pull/72476. I put the declaration
that hit this in a header, but as I thought about it... there was no real harm
in just fixing the issue and preventing future breakage.
LLVM is presumably moving towards `std::string_view` -
`StringRef::startswith` is deprecated on tip. `SmallString::startswith`
was just renamed there (maybe with some small deprecation inbetween, but
if so, we've missed it).
The `SmallString::startswith` references were moved to
`.str().starts_with()`, rather than adding the `starts_with` on
`stable/20230725` as we only had a few of them. Open to switching that
over if anyone feels strongly though.
When loading input from CAS, `swift-frontend` relies on the input file
name to determine the type to look from CAS entry. In the case where
file extension is `.private.swiftinterface`, swift mis-identify that as
`.swiftinterface` file and look up the wrong input file. Add a new
file type lookup function that can figure out the type from the full
filename.
Also add few diagnostics during the CAS lookup for the input file to
error out immediately, rather than rely on the lookup failure later.
As of CMake 3.25, there are now global variables `LINUX=1`, `ANDROID=1`,
etc. These conflict with expressions that used these names as unquoted
strings in positions where CMake accepts 'variable|string', for example:
- `if(sdk STREQUAL LINUX)` would fail, because `LINUX` is now defined and
expands to 1, where it would previously coerce to a string.
- `if(${sdk} STREQUAL "LINUX")` would fail if `sdk=LINUX`, because the
left-hand side expands twice.
In this patch, I looked for a number of patterns to fix up, sometimes a
little defensively:
- Quoted right-hand side of `STREQUAL` where I was confident it was
intended to be a string literal.
- Removed manual variable expansion on left-hand side of `STREQUAL`,
`MATCHES` and `IN_LIST` where I was confident it was unintended.
Fixes#65028.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
Use the std-equivalent names as the LLVM ones are now deprecated
(eventually `llvm::Optional` will disappear):
- `getValue` -> `value`
- `getValueOr` -> `value_or`
- `hasValue` -> `has_value`
Follow up from ab1b343dad and
7d8bf37e5e with some missing cases.
`std::chrono::high_resolution_clock` is being used in
`FrozenMultiMapTest.cpp` but it was relying on `chrono` being included
transitively. Include it directly.
I wanted a bit vector that I could use as a compact sorted
set of enum values: an inline-allocated, fixed-size array
of bits supporting efficient and convenient set operations
and iteration.
The C++ standard library offers std::bitset, but the API
is far from ideal for this purpose. It's positioned as
an abstract bit-vector rather than as a set. To use it
as a set, you have to turn your values into indices, which
for enums means explicitly casting them all in the caller.
There's also no iteration operation, so to find the
elements of the set, you have to iterate over all possible
indices, test whether they're in the set, and (if so)
cast the current index back to the enum. Not only is that
much more awkward than normal iteration, but it's also
substantially less efficient than what you can get by
counting trailing zeroes in a mask.
LLVM and Swift offer a number of other bit vectors, but
they're all dynamically allocated because they're meant
to track arbitrary sets. That's not a non-starter for my
use case, which is in textual serialization and so rather
slow anyway, but it's also not very hard to whip together
the optimal data structure here.
I have committed the cardinal sin of C++ data structure
design and provided the operations as ordinary methods
instead of operators.
This commit adds a function to remap the clang arguments passed
during compilation. This is intented to be shared across the
Swift compiler and LLDB to apply path remapping for debug info
paths.
This gives us build-time warnings about format string mistakes, like we would get if we called the built-in asprintf directly.
Make TypeLookupError's format string constructor a macro instead so that its callers can get these build-time warnings.
This reveals various mistakes in format strings and arguments in the runtime, which are now fixed.
rdar://73417805
This patch fixes the unsigned/signed comparison warnings in the
unittests caused by comparing an unsigned integer with the signed
integer literal. The offending signed integer literals have been
replaced with unsigned integer literals.
I implemented this in a similar way to the way blotting is implemented in a blot
map vector:
1. I changed this to store (Key, Optional<Value>) pairs.
2. I made it so that once frozen, we can "erase" things from the multimap by
setting all Optional<Value> to none.
3. I changed the range we vend to be an OptionalTransformRange instead of just a
TransformRange so we skip all keys with .none values, meaning that a user will
get the nice behavior that getRange() still works after erasing.
One interesting thing to note is that one /cannot/ erase elements when
initializing the frozen multi-map since we haven't sorted it yet. At first this
seems weird, but it actually fits with the use case of this data structure:
building up state by processing IR in a readonly way and then later working with
it in a worklist like way (and perhaps checking for unhandled cases at the end
of processing).
The nice thing additional thing is that I was able to ensure that the actual
exposed API did not change in terms of how one uses it. I just changed the
underlying iterators/etc.
The properties of this multimap cache are:
1. Values are stored (inline if Small) in a Vector and our map internally maps
keys to (start, length) of slices of the Vector. This is done instead of
storing arrays refs to ensure that if our array goes from small -> large, we
do not have stale pointers.
2. Values are only allowed to be inserted all at once. This is ok, since this is
a cache.
3. One is not storing individual small vectors in a map (or state storing
SmallVectors). This can inadvertantly add up to using a lot of memory and is
not needed for homogenous data.
