In an explicit build LLDB needs to be able import the unmodified .pcms, so
having the exact same flags matters there, and there is no risk of a
recompilation failure, because nothing is recompiled.
rdar://136759808
Add function to handle all macro dependencies kinds in the scanner,
including taking care of the macro definitions in the module interface
for its client to use. The change involves:
* Encode the macro definition inside the binary module
* Resolve macro modules in the dependencies scanners, including those
declared inside the dependency modules.
* Propagate the macro defined from the direct dependencies to track
all the potentially available modules inside a module compilation.
The reason why is that we want to distinguish inbetween SILFunction's that are
marked as unspecified by SILGen and those that are parsed from textual SIL that
do not have any specified isolation. This will make it easier to write nice
FileCheck tests against SILGen output on what is the inferred isolation for
various items.
NFCI.
Before the update to support the new syntax, the decl checker treated private and fileprivate members of objcImpl extensions as non-@objc by default. But SE-0436 specified that private and fileprivate members should be implicitly @objc unless opted out, so when support for the final syntax was added, this behavior was changed retroactively.
Unfortunately, we’ve found that some early adopters depended on the old behavior. Restore some logic deleted by #73309 for early adopter syntax *only*, with a warning telling the developer to put `final` or `@nonobjc` on the declaration if they want to preserve the behavior after updating it.
Also tweaks the ObjCImplementationChecker to ensure this logic will actually be run in time for it to suppress the “upgrade to @objc @implementation” warning, and corrects a couple of regressions arising from that change.
Fixes rdar://135747897.
This fixes the debugger's ability to perform expression evaluation when debugging an
executable that was built with both under the following circumstances:
1. explicit module build
2. `-application-extension`
The fix is to include `-fapplication-extension` as an XCC field in the swiftmodule.
This primes the debugger's ClangImporter with the correct flag needed to load the
explicitly built pcm files generated at build time.
Mangling this information for future directions like component lifetimes
becomes complex and the current mangling scheme isn't scalable anyway.
Deleting this support for now.
In #69257, we modified `ObjCReason` to carry a pointer to the @implementation attribute for the `MemberOfObjCImplementationExtension` kind. This made it mark the @implementation attribute as invalid, suppressing diagnostics from the ObjCImplementationChecker.
However, invalidating the attribute *also* causes it to be skipped by serialization. That isn’t a problem if the diagnostics are errors, since we’ll never emit the serialized module, but #74135 softened these diagnostics to warnings for early adopters.
The upshot was that if Swift emitted one of these warnings when it compiled a library, clients of that library would see the objcImpl extension as a normal extension instead. This would cause various kinds of mischief: ambiguous name lookups because implementations weren’t being excluded, overrides failing because an implementation was `public` instead of `open`, asserts and crashes in SILGen and IRGen because stored properties were found in seemingly normal extensions, etc.
Fix this by setting a separate bit on ObjCImplementationAttr, rather than the invalid bit, and modifying the implementation checker to manually suppress many diagnostics when that bit is set.
Fixes rdar://134730183.
10.50 was once greater than any real macOS version, but now it compares
less than real released versions, which makes these tests depend on the
deployment target unnecessarily. Update these tests to use even larger
numbers to hopefully keep them independent a little longer.
This diagnostic reports when two compilers that are marked as targetting
different distribution channels try to read swiftmodules produced by the
other one. For a resilient module, this error is usually silently ignored
as the reader compiler picks the swiftinterface over the swiftmodule.
It is visibile to the end user when the module is non-resilient.
For such a case, we here try to improve the diagnostic to be more
meaningful.
The new diagnostics looks like so:
```
import ChannelLib // error: the binary module for 'ChannelLib' was compiled
// for 'restricted-channel', it cannot be imported by the
// current compiler which is aligned with 'other-channel'.
// Binary module loaded from path: .../ChannelLib.swiftmodule
```
Vendors should be mindful to pick meaningful channel names
to guide users in the direction of the actual solution.
Some editors use diagnostics from SourceKit to replace build issues. This causes issues if the diagnostics from SourceKit are formatted differently than the build issues. Make sure they are rendered the same way, removing most uses of `DiagnosticsEditorMode`.
To do so, always emit the `add stubs for conformance` note (which previously was only emitted in editor mode) and remove all `; add <something>` suffixes from notes that state which requirements are missing.
rdar://129283608
