ConditionalClauseInitializerScope often create redundant scopes, however, they
are needed to correctly represent the scopes in an expression such as:
if case .something(let foo), let foo = foo.
This patch changes SILGen to lower them 1:1 from ASTScopes.
rdar://110841130
- Renames ExperimentalPlatformCCallingConvention to
PlatformCCallingConvention.
- Removes non-arm calling convention support as this feature is working
around a clang bug for some arm triples which we hope to see resolved.
- Removes misleading MetaVarName from platform-c-calling-convention
argument.
- Replaces other uses of LLVM::CallingConv::C with
IGM.getOptions().PlatformCCallingConvention().
Adds a new swift-frontend flag to allow users to choose which calling
convention is used to make c function calls. This hidden flag is called
`-experimental-platform-c-calling-convention`.
This behavior is needed to workaround rdar://109431863 (Swift-frontend
produces trapping llvm ir for non-trapping sil). The root cause of this
issue is that IRGen always emits c function calls with llvm's default C
calling convention. However clang may select a different (incompatible)
calling convention for the function, eventually resulting--via
InstCombine and SimplifyCFG--in a trap instead of the function call.
This failure mode is most readily seen with the triple
`armv7em-apple-none-macho` when attempting to call functions taking
struct arguments. Example unoptimized ir below:
```llvm-ir
call void @bar([4 x i32] %17, i32 2), !dbg !109
...
define internal arm_aapcs_vfpcc void @bar(
[4 x i32] %bar.coerce, i32 noundef %x)
```
In the future it would be better to use the clang importer or some other
tool to determine the calling convention for each function instead of
setting the calling convention frontend invocation wide.
Note: I don't know for sure whether or not clang should be explicitly
annotating these functions with a calling convention instead of
aliasing C to mean ARM_AAPCS_VFP for this particular combination of
`-target`, `-mfloat-abi`, and `-mcpu`.
Record up to two errors emitted when we fail to
load a module for interface generation, and include
these errors in the message we pass back to the
editor. This should help us better pin down the
reason why interface generation failed.
rdar://109511099
Previously only stored properties could be initializable but with
introduction of init accessors computed properties gained an ability
to specify initialzer expression and participation in memberwise
initialization for structs.
Sometimes it's useful to be more lenient when type checking swiftinterfaces
since restrictions that could be dropped in the future will manifest in
resilient libraries being incompatible with older compilers otherwise.
'load-plugin-library', 'load-plugin-executable', '-plugin-path' and
'-external-plugin-path' should be searched in the order they are
specified in the arguments.
Previously, for example '-plugin-path' used to precede
'-external-plugin-path' regardless of the position in the arguments.
stripping PackType out of diagnostic arguments.
There are places in the type printing code that assume the substitution for a
type parameter pack is always a pack, and violating that invariant will crash
the compiler. We also never want to print 'Pack{...}' in diagnostics anyway,
so the print option is a better approach and fixes a few existing tests that still
contained 'Pack{...}' in error messages.
@objcImpl extensions aren’t allowed to declare new conformances; instead, they should either be declared in the header or in an ordinary extensions. (If they were permitted, they’d be ignored.)
Fixes rdar://110669366.
`lib/swift/host` contains modules/libraries that are built by the host
compiler. Their `.swiftmodule` will never be able to be read, ignore
them entirely.
Teach swift dependency scanner to use CAS to capture the full dependencies for a build and construct build commands with immutable inputs from CAS.
This allows swift compilation caching using CAS.
namespace.
This moves the `isInMacroArgument` predicate and `lookupMacros` into `namelookup`.
ASTScope still encapsulates the scope tree and contains the operation to lookup
the enclosing macro scope, which then invokes a callback to determine whether a
potential macro scope is indeed a macro, because answering this question requires
name lookup.
names at global scope.
Freestanding and peer macros applied at top-level scope cannot introduce
arbitrary names. Introducing arbitrary names means that any lookup
into this scope must expand the macro. This is a problem, because
resolving the macro can invoke type checking other declarations, e.g.
anything that the macro arguments depend on. If _anything_ the macro
depends on performs name unqualified name lookup, e.g. type resolution,
we'll get circularity errors. It's better to prevent this by banning
these macros at global scope if any of the macro candidates introduce
arbitrary names.
This source location will be used to determine whether to add a name lookup
option to exclude macro expansions when the name lookup request is constructed.
Currently, the source location argument is unused.
so that it can represent the scope for any custom attribute and its arguments.
This commit is NFC, but CustomAttributeScope is now applicable to attached macros.
Now that we've made accessor macro expansion more lazy, ensure that
when querying for init accessors (e.g., to build a memberwise
initializer), we also expand any accessor macros that might produce an
init accessor.
This is a partial step toward the real goal, which is that
`AbstractStorageDecl::getAccessor()` should lazily expand macros if
needed.
Update the Observable macro to document that it produces an `init`
accessor.
The `hasStorage()` computation is used in many places to determine the
signatures of other declarations. It currently needs to expand accessor
macros, which causes a number of cyclic references. Provide a
simplified request to determine `hasStorage` without expanding or
resolving macros, breaking a common pattern of cycles when using
macros.
Fixes rdar://109668383.
