Add ModuleInterface option meta tag for -module-alias
Add tests loading modules with -module-alias for swiftmodule and swiftinterface
with various loaders incl. serialized, explicit, and source loader.
The Swift driver is passing the optimization record file path via the supplementals output, instead of the flag, on certain circumstances.
Enhance the frontend to check supplemental outputs otherwise the record file will not get emitted when using the new swift driver.
Outputting the effective version in the pretty stack trace was skipped
if the current version was the same as the effective version. This would
result in an empty line, which is somewhat confusing. Output a line
regardless.
Resolves rdar://81140703
- If any of the `-g<kind>` flag is given -- except `-gnone`, debug
info will be printed into every generated SIL files.
- The `-gsil` is deprecated in favor of `-sil-based-debuginfo`. The
SILDebugInfoGenerator Pass now generates intermediate SIL file with
name "<output file>.sil_dbg_<n>.sil". Other functionalities of that
Pass remain the same.
Rather than outputting diagnostics and to stderr, output all the extra
information added when deserialization fatally fails to the pretty stack
trace instead. Since the pretty stack trace is added to crash logs, this
should avoid the dance of requesting the compiler output
- Moves the previous "**** DESERIALIZATION FAILURE ..." output to the
last pretty stack trace line
- Removes the module and compiler version notes added to the fatal
diagnostic
- Adds a new effective compiler version line for all frontend failure.
Somewhat duplicates the line from the driver, but adds in the
effective version
- Adds a new line for the full misc version of the module that failed.
May double up with previous "While reading from ..." lines that are
added in various deserialization methods, but better to have it
twice than not at all
It's currently not obvious in crash reports whether compiling with
errors is enabled or not. Since this option can make previously
"impossible" paths now possible, add a message to both the pretty stack
output and fatal deserialization diagnostics to point out that it is
enabled.
When allowing errors with
-experimental-allow-module-with-compiler-errors, do not output the
.swiftinterface when there has been errors. There's no real need to
output them for invalid modules, so this avoids module interface
printing having to have checks for normally-impossible cases.
Resolves rdar://78039608.
When compiling with allow errors, it's possible to have invalid
inherited types - both null and ErrorType.
Cleaned up the tests a little - moved the majority of
Frontend/allow-errors.swift into separate files in
Serialization/AllowErrors and use split_file.py instead of #defines.
Resolves rdar://78048470
* [Diagnostics] Use DeclDescriptiveKind on data flow diagnostics to improve diagnostic message
* [tests] Add regression tests to SILOptimizer/return.swift
* [tests] Adapt other tests to changes of SR-14505
* [Diagnostics] Adapt message for missing return diagnostics, remove article
* [Diagnostics] Adapt message for missing return diagnostics to have a note with fix
* [tests] Adjust tests in validation suit
When allowing errors there's various cases where an invalid type is used
during serialization:
- Invalid explicit conformances on an extension
- Superclass with invalid generic type
Add checks to skip these to avoid crashing.
Resolves rdar://75379780.
47b068d445 output a diagnostic if a
deserialized decl was invalid (checking `Decl::isInvalid`). It had two
major issues:
1. It incorrectly output diagnostics for valid modules
2. It did not catch call invalid declarations
(1) is caused by `isInvalid` falling back to checking the storage for
accessors when the interface type hasn't already been computed (a
fallback to prevent a cycle due to `SimpleDidSetRequest` typechecking
the body). Since the `VarDecl` hasn't finished deserializing, it returns
`true` for its `isInvalid` check (even though it would later return
`false`).
For (2), only `ValueDecl`s would ever be invalid, since other
declarations use a bit in `Decl` to check for validity. As that's not
serialized, those would always be valid in deserialization.
To avoid both these issues, instead output a flag for each declaration
representing whether it is invalid (or not). Read that during
deserialization and output a diagnostic if it is invalid. To be extra
sure that a diagnostic is always output on an error, also output one
when deserializing any `ErrorType`. This ensures that SILGen does not
run when allowing errors (and an error is present), as it is likely to
crash when presented with an invalid AST.
Resolves rdar://74541834
When running in the allow errors mode
(-experimental-allow-module-with-compiler-errors), modules may contain
invalid declarations. The rest of the compiler pipeline, however,
expects to have valid declarations unless diagnostics have emitted an
error. Emit an error while deserializing to maintain this assumption.
Note that these errors will not have a useful location, unless there's a
corresponding `.swiftsourceinfo`. This isn't a problem for the intended
use case in IDEs, where diagnostics outside the current file would be
ignored anyway.
Since reading declarations is lazy, SILGen (and thus SIL diagnostics)
can still run as long as any invalid declarations weren't referenced in
the compiling module.
Resolves rdar://74325388
Introducing new entry-points that can be used from both Driver and Frontend clients, using an intermediary new type: `DetailedMessagePayload`, when needed.
Also, continue trying opening files even if any of primary files are
missing so that the caller can know all files failed to open.
rdar://problem/33757793
This frontend flag can be used as an alternative to
-experimental-skip-non-inlinable-function-bodies that doesn’t skip
functions defining nested types. We want to keep these types as they are
used by LLDB. Other functions ares safe to skip parsing and
type-checking.
rdar://71130519
