Revert "Fix complete_decl_attribute test for @fixed_layout"
Revert "Sema: non-@objc private stored properties do not need accessors"
Revert "Sema: Access stored properties of resilient structs through accessors"
Revert "Strawman @fixed_layout attribute and -{enable,disable}-resilience flags"
This reverts commit c91c6a789e.
This reverts commit 693d3d339f.
This reverts commit 085f88f616.
This reverts commit 5d99dc9bb8.
A fixed layout type is one about which the compiler is allowed to
make certain assumptions across resilience domains. The assumptions
will be documented elsewhere, but for the purposes of this patch
series, they will include:
- the size of the type
- offsets of stored properties
- whether accessed properties are stored or computed
When -enable-resilience is passed to the frontend, all types become
resilient unless annotated with the @fixed_layout attribute.
So far, the @fixed_layout attribute only comes into play in SIL type
lowering of structs and enums, which now become address-only unless
they are @fixed_layout. For now, @fixed_layout is also allowed on
classes, but has no effect. In the future, support for less resilient
type lowering within a single resilience domain will be added, with
appropriate loads and stores in function prologs and epilogs.
Resilience is not enabled by default, which gives all types fixed
layout and matches the behavior of the compiler today. Since
we do not want the -enable-resilience flag to change the behavior
of existing compiled modules, only the currently-compiling module,
Sema adds the @fixed_layout flag to all declarations when the flag
is off. To reduce the size of .swiftmodule files, this could become
a flag on the module itself in the future.
The reasoning behind this is that the usual case is building
applications and private frameworks, where there is no need to make
anything resilient.
For the standard library, we can start out with resilience disabled,
while perfoming an audit adding @fixed_layout annotations in the
right places. Once the implementation is robust enough we can then
build the standard library with resilience enabled.
This means: handling of alloc_ref [stack].
It can be configured with two new options. See Option/FrontendOptions.td.
As the [stack] attribute is not generated yet, there should be NFC.
Swift SVN r32929
My temporary hackery around inferring default arguments from imported
APIs was too horrible. Make it slightly more sane by:
1) Actually marking these as default arguments in the type system,
rather than doing everything outside of the type system. This is a
step closer to what we would really do, if we go in this
direction. Put it behind the new -frontend flag
-enable-infer-default-arguments.
2) Only inferring a default argument from option sets and from
explicitly "nullable" parameters, as stated in the (Objective-)C API
or API notes. This eliminates a pile of spurious, non-sensical "=
nil"'s in the resulting output.
Note that there is one ugly tweak to the overloading rules to prefer
declarations with fewer defaulted arguments. This is a bad
implementation of what is probably a reasonable rule (prefer to bind
fewer default arguments), which intentionally only kicks in when we're
dealing with imported APIs that have default arguments.
Swift SVN r32078
The new option -Womit-needless-words finds places where names are
redundant with type information, producing warnings and Fix-Its to
shorten the names. Part of rdar://problem/22232287, to help bring
the same heuristics we're applying in the Clang importer to the user's
Swift code.
Swift SVN r31234
The -enable-omit-needless-words option attempts to omit needless words
from method names imported from Clang. Broadly speaking, a word is
needless if it merely restates the type of the corresponding parameter,
using reverse camel-case matching of the type name to the
function/parameter name. The word "With" is also considered needless
if whether follows it is needless, e.g.,
func copyWithZone(zone: NSZone)
gets reduced to
func copy(zone: NSZone)
because "Zone" merely restates type information and the remaining,
trailing "With" is also needless.
There are some special type naming rules for builtin Objective-C types,
e.g.,
id -> "Object"
SEL -> "Selector"
Block pointer types -> "Block"
as well as some very-Cocoa-specific matching rules, e.g., the type
"IndexSet" matches the name "Indexes" or "Indices".
Expect a lot of churn with these heuristics; this is part of
rdar://problem/22232287.
Swift SVN r31178
Compute the hash of all interface tokens when parsing; write the
interface hash to the swiftdeps file, or if the -dump-interface-hash
option is passed to the frontend. This hash will be used in incremental
mode to determine whether a file's interface has changed, and therefore
whether dependent files need to be rebuilt in response to the change.
Committed on ChrisW's behalf while he gets his setup unborked.
rdar://problem/15352929
Swift SVN r30477
This frontend option allows one to turn off autolinking to the
specified framework. This general capability is motivated by
rdar://problem/21246363, where we need to turn off some autolinking in
our overlays due to internal vs. public SDK differences.
Swift SVN r29393
I was always confused by the inconsistency of -sil-print-all and the other -sil-print options.
So I thought it would be a good idea to make -sil-print-all also an llvm option.
Together with some other internal options which are only used in the pass manager.
Swift SVN r29365
The last remaining case was apparently @objc generic classes, which
seem to work now.
Also nuke the IRGen/unimplemented_objc_generic_class.swift test,
this is now implemented and we have other tests that test this
functionality.
Swift SVN r29260
The last remaining case was apparently @objc generic classes, which
seem to work now.
Also nuke the IRGen/unimplemented_objc_generic_class.swift test,
this is now implemented and we have other tests that test this
functionality.
Swift SVN r29138
Now that we are using OptionSetType for option sets, all the support for
doing things the old way can die.
Note: the fix-it that used to apply to RawOptionSetType, it seemed to me,
should still apply to OptionSetType, so I switched it over instead of
removing it.
Swift SVN r29066
When -enable-simd-import is active, if we encounter a vector type, try to load the SIMD Swift module, and if successful, map float, double, and int vectors to SIMD.{Float,Double,Int}N types if they exist.
Swift SVN r27367
Previously, the only way to get initializers was completing after the
name of the type:
Foo#^complete_here^#
Foo(#^or_here^#
And now it will also work in unadorned expressions:
#^a_top_level_completion^#
bar(a, #^walked_into_a_bar^#
Unfortunately, not all our clients handle this well yet, so it's
protected by a language option.
-code-complete-inits-in-postfix-expr
Swift SVN r27275
Enable checking for uses of potentially unavailable APIs. There is
a frontend option to disable it: -disable-availability-checking.
This commit updates the SDK overlays with @availability() annotations for the
declarations where the overlay refers to potentially unavailable APIs. It also changes
several tests that refer to potentially unavailable APIs to use either #available()
or @availability annotations.
Swift SVN r27272
We're not going to require the type parameters to be redeclared on
extensions of generic types, so take away the staging option and
diagnostic.
Swift SVN r26854
In particular, this is problematic when libraries are loaded dynamically, and
may have newer deployment targets than the main executable.
Swift SVN r26786
...which allows "@testable import" to work with modules not compiled for
testing. This isn't generally safe, but should be fine for clients like
SourceKit which just need to have the API available and might not be able
to properly rebuild the original target for testing.
We may revisit this in the future.
Swift SVN r26629
This flag enables checking of availability (deprecation, explicit unavailability,
and potential unavailability) in synthesized functions. The flag will go away once this
checking is fully staged in.
Swift SVN r26624
SIL seems to be doing the right thing here already, which is great!
Part of rdar://problem/17732115. We'll be able to really see this working
with the next change: allowing references to testable things when using
"@testable import".
Swift SVN r26473
This warning is temporarily going being a flag so that, once it is safe to place generic parameters on extensions of generic types, we can opt-in to update our code when it is convenient.
Swift SVN r26416
This flag indicates that internal APIs within the module should be made
available to client code for testing purposes. Currently does nothing.
Not ready for developer consumption yet, ergo a hidden frontend-only flag.
Part of testability (rdar://problem/17732115)
Swift SVN r26292
Together with -wmo it enables multi-threaded compilation.
I didn't want to reuse the -j option for this, because -num-threads (even if n == 1) does change the generated code.
For details see commit message of r25930.
Swift SVN r26258
Since a function pointer doesn't carry any context, we can only form a C function pointer from a static reference to a global function or a context-free local function or closure. (Or maybe a static function applied to its metatype, but that's not handled here yet.) As a placeholder for a to-be-bikeshedded surface syntax, let the existing @cc(cdecl) attribute appear in source text when the -enable-c-function-pointers frontend flag is passed.
Swift SVN r25308
We've had a rash of bugs due to inconsistencies between how IRGen and the runtime think types are laid out. Add a '-verify-type-layout' mode to the frontend that causes IRGen to emit a bunch of code that compares its static assumptions against what the runtime value witness does.
Swift SVN r24918
This implicitly adds the named module as an import of every source file
in the module being compiled. This is not intended to be used generally,
but will be useful for playgrounds.
rdar://problem/19605934
Swift SVN r24905
