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.
(cherry picked from commit 414adb55ca)
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.
(cherry picked from commit 7f2649ff33)
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.
(cherry picked from commit 4909b9baed)
-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
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.
(cherry picked from commit 18703d64d6)
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.
(cherry picked from commit 55bd906906)
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
(cherry picked from commit dfa4a27ec8)
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`
This only takes the existing AST information and writes it as JSON
instead of S-expressions. Since many of these fields are stringified,
they're not ideal for the kind of analysis clients of the JSON format
would want to do. A future commit will update these values to use a
more structured representation.
Parsing for `-enable-upcoming-feature` and `-enable-experimental-feature` is
lenient by default because some projects need to be compatible with multiple
language versions and compiler toolchains simultaneously, and strict
diagnostics would be a nuisance. On the other hand, though, it would be useful
to get feedback from the compiler when you attempt to enable a feature that
doesn't exist. This change splits the difference by introducing new diagnostics
for potential feature enablement misconfigurations but leaves those diagnostics
ignored by default. Projects that wish to use them can specify `-Wwarning
StrictLanguageFeatures`.
