This patch fixes the access check for nested private C++ enums to look for the SWIFT_PRIVATE_FILEID of the enclosing C++ class, if any. Previously, the check was looking at for SWIFT_PRIVATE_FILEID on the enum decl itself (which is meaningless); that prevented nested private enum members from being accessible in Swift.
This patch also specializes the type signature of getPrivateFileIDAttrs to clarify the fact that SWIFT_PRIVATE_FILEID is not a meaningful annotation on anything other than CXXRecordDecl, because that is the only kind of decl that can assign access specifiers to its members.
rdar://148081340
Building on top of PR #79288, this update synthesizes a static factory method using the default new operator, with a call to the default constructor expression for C++ foreign reference types, and imports them as Swift initializers.
rdar://147529406
Specifically, when the scanner found a candidate which does not carry a user-specified version, it will pass '-module-can-import Foo' to compilation. During compilation, if the check is versioned but the candidate is unversioned, evaluate the check to 'true' to restore the behavior we had with implicitly-built modules.
Resolves rdar://148134993
`llvm::sys::Wait(process, /*SecondsToWait=*/0)` perform a non-blocking
`wait`. That means the plugin goes a zombie if it hasn't exited.
Set `SecondsToWait` 1 so it wait for 1 second and kill it on the time
out. Usually, when the pipe is closed, the plugins detect the EOF in
stdin and exits immediately, fo the parent process usually don't wait
for the timeout.
rdar://148110944
It doesn't seem like this is necessary anymore since we no longer
clone OverrideAttrs when checking overrides (except when
invalidating). Moreover, it's now actively wrong since accessors
introduced by macro expansions may be in different buffers than their
their storage, so checking `isBeforeInBuffer` will non-deterministically
result in the wrong source range.
Specifically:
1. I made it so that thunks from caller -> concurrent properly ignore the
isolated parameter of the thunk when calling the concurrent function.
rdar://148112362
2. I made it so that thunks from concurrent -> caller properly create a
Optional<any Actor>.none and pass that into the caller function.
rdar://148112384
3. I made it so that in cases where we are assigning an @Sendable caller to a
non-sendable caller variable, we allow for the conversion as long as the
parameters/results are sendable as well.
rdar://148112532
4. I made it so that when we generate a thunk from @execution(caller) ->
@GlobalActor, we mangle in @GlobalActor into the thunk.
rdar://148112569
5. I discovered that due to the way we handle function conversion expr/decl ref
expr, we were emitted two thunks when we assigned a global @caller function to a
local @caller variable. The result is that we would first cast from @caller ->
@concurrent and then back to @caller. The result of this would be that the
@caller function would always be called on the global queue.
rdar://148112646
I also added a bunch of basic tests as well that showed that this behavior was
broken.
Print diagnostic groups as part of the LLVM printer in the same manner as the
Swift one does, always. Make `-print-diagnostic-groups` an inert option, since we
always print diagnostic group names with the `[#GroupName]` syntax.
As part of this, we no longer render the diagnostic group name as part
of the diagnostic *text*, instead leaving it up to the diagnostic
renderer to handle the category appropriately. Update all of the tests
that were depending on `-print-diagnostic-groups` putting it into the
text to instead use the `{{documentation-file=<file name>}}`
diagnostic verification syntax.
We've been converging the implementations of educational notes and
diagnostic groups, where both provide category information in
diagnostics (e.g., `[#StrictMemorySafety]`) and corresponding
short-form documentation files. The diagnostic group model is more
useful in a few ways:
* It provides warnings-as-errors control for warnings in the group
* It is easier to associate a diagnostic with a group with
GROUPED_ERROR/GROUPED_WARNING than it is to have a separate diagnostic
ID -> mapping.
* It is easier to see our progress on diagnostic-group coverage
* It provides an easy name to use for diagnostic purposes.
Collapse the educational-notes infrastructure into diagnostic groups,
migrating all of the existing educational notes into new groups.
Simplify the code paths that dealt with multiple educational notes to
have a single, possibly-missing "category documentation URL", which is
how we're treating this.
This feature only exists as a mechanism to suppress the warning introduced in
https://github.com/swiftlang/swift/pull/75378. The RegexParser module, which is
effectively part of the standard library, declares a Swift runtime symbol and
as a result every build of the compiler and stdlib produces warnings which
there are no plans to address. Warnings that are not going to be addressed need
some way of being suppressed, and an experimental features seems like a
reasonable mechanism for this one.
If an `@objc implementation extension` had a public stored property with an observer, Swift would print `@_hasStorage` on the extension. This is Not Good because in a module interface, an objcImpl extension appears to be an ordinary extension, and properties in ordinary extensions are not supposed to have storage.
Suppress printing this attribute in objcImpl extensions to avoid this problem.
Partially fixes rdar://144811653 by suppressing emission of bad attributes.
The last step in building a generic signature is to sort the requirements.
Requirements are sorted by comparing their subject types. If two
requirements have the same subject type, which can only happen with
conformance requirements, we break the tie by comparing protocol
declarations.
We compare protocol declarations using TypeDecl::compare(), which is a
shortlex order on the components of the fully qualified name of a
protocol (eg, Swift.Sequence, etc.)
While this order is part of the ABI, it has not been updated over the
years for several important changes:
- It did not handle module aliases; if we import a module via an
alias, we should use the real module name to compare protocols, and
not the aliased name. This produced inconsistent results if the
same module was imported under different names, which can happen
with module interface files that use module aliases.
- It did not handle the -module-abi-name flag. Changing the ABI name
of a module changes how we mangle protocol names, and the order
should match the mangling.
This change fixes the first case only. The second requires more
careful staging, because of _Concurrency and CompilerSwiftSyntax.
Fixes rdar://147441890.
