Optional language features don't have a specific "-enable-*" flag, because
they're rare and don't fit the same upcoming/experimental distinction. Add
a flag_name field to provide the flag name as well.
The name of a migratable feature might differ from the names of the
diagnostic groups containing the diagnostics that are used to drive
migration for that feature. Provide the set of diagnostic categories
that are associated with each migratable feature as part of the
supported features list.
-nostdimport and -nostdlibimport only remove the toolchain and usr/lib/swift search paths, and they leave the framework search paths intact. That makes it impossible to get a fully custom SDK environment. Make their behavior match clang's -nostdinc/-nostdlibinc behavior: treat framework and non-framework paths the same. In other words, -nostdinc removes *all* compiler provided search paths, and -nostdlibinc removes *all* SDK search paths.
Rename SkipRuntimeLibraryImportPaths to SkipAllImportPaths, and ExcludeSDKPathsFromRuntimeLibraryImportPaths to SkipSDKImportPaths to reflect their updated behavior.
Move the DarwinImplicitFrameworkSearchPaths handling from SearchPathOptions to CompilerInvocation, where RuntimeLibraryImportPaths is managed. Rename it to just ImplicitFrameworkSearchPaths, and filter for Darwin when it's set up so that all of the clients don't have to do Darwin filtering themselves later.
rdar://150557632
This is future-proofing the version part of the upcoming
feature. There currently no features that require that
but it's possible that they'd be added in the future.
The "featues" part was never actually implemented and Swift Driver
is replying on information about arguments, so instead of removing
this mode, let's scope it down to "arguments" to be deprecated in
the future.
This is a replacement for `-emit-supported-features` that prints
all of the upcoming/experimental features supported by the compiler
with some additional meta information in JSON format to stdout.
SymbolGraph generation iterating over llvm::DenseSet, which makes the
symbols and relationship fields appear in non-deterministic ordering.
Switch to use llvm::SetVector to preserve the insertion order from
SourceEntityWalker to make order deterministic.
Resolves: https://github.com/swiftlang/swift/issues/59602
- For type USRs, use `mapTypeOutOfContext()` to replace primary
archetypes with type parameters. If the type contains local
archetypes, replace them with their existential upper bounds.
- For inheritance of types, print the derived semantic information
instead of the inheritance list as it is written.
- Dump conformance requirements as protocol decl USRs instead of
type USRs, since the latter involves an existential conversion
that loses suppressed protocols.
- Fix a small bug in conformance dumping where the `MemberLoading`
field wasn't propagated to the nested printer, which caused
protocols to be dumped as simple names instead of USRs.
PR #78793 moved the code that this test was testing for into `NDEBUG`
blocks, which means that only exist in assert toolchains. The test was
not changed, so it was failing in non-assert toolchains.
Use a null diagnostic consumer in the deterministic verify instance. The
constraint system will skip work if there are no consumer in the
diagnostic engine. Use a null consumer to make sure the same amount of
work is done for two runs.
Make sure the traversal order for classMembers in deterministic in the
mdoule by sorting them first.
Also fix the comparsion function for `DeclName` to make sure there
aren't two DeclNames with different OpaquePointer can be evaluated to
equal.
rdar://147513165
Fix the non-deterministic .swiftdeps output. In contrary to the comments
in the `FineGrainedDependencies.h`, the non-determinism is not because
of the use of unordered_* data structure there. Those data structures
are not traversed so removing all the unused traversing methods to avoid
the confusion.
The true reason for the non-determinism is all the DenseSet in the
Evaluator dependency tracking, that causes the FineGrainedDependencies
to see arbitrary ordering. Use `SetVector` instead to keep track of the
insertion order to make dependency output to be deterministic.
rdar://104876331
`#fileID` never accounted for the possibility that someone one have
a module alias _itself_, so it always generated the module's real
(physical) name. This _technically_ changes the behavior of `#fileID`
for self-aliased modules, but since nobody would have ever had a reason
to do that before raw identifiers, it's unlikely that this change would
affect anyone in practice.
For build systems that already generate these files, it makes sense to include the aliases so that the map file serves as a comprehensive index of how the module inputs are referenced.
The original module names themselves must still be valid unescaped identifiers; most of the serialization logic in the compiler depends on the name of a module matching its name on the file system, and it would be very complex to turn escaped identifiers into file-safe names.
Keep track of all of the type parameters and archetypes that are captured
by a local function or closure. Use that information to diagnose cases
where a non-Sendable metatype crosses an isolation boundary.
* Include `DeclContext` of the node where possible
* Add 'default-with-decl-contexts' dump style that dumps the dect context
hierarchy in addition to the AST
* Support `-dump-parse` with `-dump-ast-format json`
