This cleans up 90 instances of this warning and reduces the build spew
when building on Linux. This helps identify actual issues when
building which can get lost in the stream of warning messages. It also
helps restore the ability to build the compiler with gcc.
These modules are part of the experimental declarative string processing feature. If accepted to the Standard Library, _StringProcessing will be available via implicit import just like _Concurrency, though _MatchingEngine will still be hidden as an implementation detail.
`_MatchingEngine` will contain the general-purpose pattern matching engine ISA, bytecode, and executor. `_StringProcessing` will contain regular expression and pattern matching APIs whose implementation depends on the matching engine..
Also consolidates frontend flag `-enable-experimental-regex` as `-enable-experimental-string-processing`.
Resolves rdar://85478647.
`WidthPreservingAPIntDenseMapInfo` uses the same `getHashValue` and
`isEqual` as the normal `DenseMapInfo` but with different empty and
tombstone keys. `hash_value` is no longer a complete type, so just
delegate to `DenseMapInfo<APInt>` rather than add another `#include`.
`WidthPreservingAPIntDenseMapInfo` uses the same `getHashValue` and
`isEqual` as the normal `DenseMapInfo` but with different empty and
tombstone keys. `hash_value` is no longer a complete type, so just
delegate to `DenseMapInfo<APInt>` rather than add another `#include`.
The key thing is that the move checker will not consider the explicit copy value
to be a copy_value that can be rewritten, ensuring that any uses of the result
of the explicit copy_value (consuming or other wise) are not checked.
Similar to the _move operator I recently introduced, this is a transparent
function so we can perform one level of specialization and thus at least be
generic over all concrete types.
These include _move and @_noImplicitCopy. I still need to wire up the parsing of
those behind this feature.
The reason that I am adding this now is that I am going to now need to make some
changes behind a feature flag and I have not yet needed to add one. The specific
reason I needed to add one here is to ensure that I properly guard inside _move
the call to Builtin.move so as to prevent a "cond_fail" incident.
P.S.: This work depends on experimental lexical lifetimes being enabled as well,
so I did that at the same time in this PR.
Previously, the flag was a LangOptioins. That didn't make much sense because
this isn't really a user-facing behavior. More importantly, as a member
of that type type it couldn't be accessed when setting up pass
pipelines. Here, the flag is moved to SILOptions.
This additional supplement output should capture semantic info the compiler has
captured while building a Swift module. Similar to the source info file, the content of
the semantic info file should only be consumed by local tooling written in Swift.
