When we encounter an input or output with an unknown extension 'TY_INVALID', still produce valid JSON specifying the type as "unknown" instead of either crashing or producing malformed JSON.
Resolves rdar://94348593
This change extends the clang header printer to start emitting C++ classes for Swift struct types with the correct struct layout in them (size + alignment)
Swiftc port of https://github.com/apple/llvm-project/pull/4207.
This introduces a new flag, `-file-prefix-map` which can be used
instead of the existing `-debug-prefix-map` and `-coverage-prefix-map`
flags, and also remaps paths in index information currently.
FrontendTool sets up diagnostic infrastructure early and suppresses stdout diagnostics if frontend-parseable-output is enabled. It then calls `CompilerInstance.setup` which may fail - if it fails, we exit early. But that means we have not gotten a chance to emit parseable-output.
This change moves emission of the `began` parseable message to before `CompilerInstance.setup`, and ensures that a corresponding `finished` message is emitted if the setup fails.
Resolves rdar://93187783
Generation of valid JSON output for parseable output depends on being able to determine file types of inputs and outputs of compilation tasks. FileTypes.def defines multiple file kinds with multiple '.' extensions, such as '.abi.json' or '.features.json', but existing code attempted to compute file outputs only using the trailing suffix of the path after the last '.'. This led to some files not being recognized, which led to us not being able to generate valid JSON.
Resolves rdar://92961252
So far, the swift-frontend decided by itself if CMO can be enabled. This caused problems when used with an old driver, which doesn't consider CMO.
Now, the driver decides when to use default CMO by passing this flag to swift-frontend.
This change removes the -emit-cxx-header option, and adds a new -emit-clang-header-path option instead. It's aliased to -emit-objc-header-path for now, but in the future, -emit-objc-header-path will alias to it. After this change Swift can start emitting a single header file that can be expose declarations to C, Objective-C, or C++. For now C++ interface is generated (for all public decls) only when -enable-cxx-interop flag is passed, but that behavior will change once attribute is supported.
`-dump-scope-maps` and `-dump-type-refinement-contexts` now dump out the content they're designed to emit even when there's an error during semantic analysis that would previously have stopped them from running.
Add new `-print-ast-decl` frontend option for only printing declarations,
to match existing behavior.
Some tests want to print the AST, but don't care about expressions.
The existing `-print-ast` option now prints function bodies and expressions.
Not all expressions are printed yet, but most common ones are.
This patch introduces new diagnostics to the ClangImporter to help
explain why certain C, Objective-C or C++ declarations fail to import
into Swift. This patch includes new diagnostics for the following entities:
- C functions
- C struct fields
- Macros
- Objective-C properties
- Objective-C methods
In particular, notes are attached to indicate when any of the above
entities fail to import as a result of refering an incomplete (only
forward declared) type.
The new diangostics are hidden behind two new flags, -enable-experimental-clang-importer-diagnostics
and -enable-experimental-eager-clang-module-diagnostics. The first flag emits diagnostics lazily,
while the second eagerly imports all declarations visible from loaded Clang modules. The first
flag is intended for day to day swiftc use, the second for module linting or debugging the importer.
PublicCMOSymbols stores symbols which are made public by cross-module-optimizations.
Those symbols are primarily stored in SILModule and eventually used by TBD generation and validation.
Instead of checking that the stdlib can be loaded in a variety of places, check it when setting up the compiler instance. This required a couple more checks to avoid loading the stdlib in cases where it’s not needed.
To be able to differentiate stdlib loading failures from other setup errors, make `CompilerInstance::setup` return an error message on failure via an inout parameter. Consume that error on the call side, replacing a previous, more generic error message, adding error handling where appropriate or ignoring the error message, depending on the context.
The logic to do or not the validation of TBD against IR was incorrect.
In the case of modules, the comment described what was supposed to
happen (skipping the validation if the module had SIB files), but the
code was returning if the module had or not SIB files, which would have
returned true for any module without SIB files without checking if the
compiler was build in a debug configuration or not.
This was only visible in the case of non-debug builds, and it only
appeared for us in a convoluted mix of optimized builds with
-enable-testing on some modules.
While this will be in the compiler arguments, it's easy to miss when
skimming over the pretty stacktrace. Add an explicit message to make it
easier to see while looking over crashes.
llvm-project `ErrorHandling.h` was updated to remove std::string. This
added a new `report_fatal_error` overload taking a `const Twine &`,
removed the overload that took `const std::string &`, and updated
`fatal_error_handler_t` to use `const char *` rather than `const
std::string &`.
Fix uses of these functions to take into account these updates. Note
that without the `const std::string &` overload, passing a `std::string`
into `report_fatal_error` now results in an ambiguous match between the
`StringRef` and `Twine` overloads so we need to be explicit about one or
the other.
Leaks checking is not thread safe and e.g. lldb creates multiple SILModules in multiple threads, which would result in false alarms.
Ideally we would make it thread safe, e.g. by putting the instruction counters in the SILModule, but this would be a big effort and it's not worth doing it. Leaks checking in the frontend's and SILOpt's SILModule (not including SILModules created for module interface building) is a good enough test.
rdar://84688015
