- In AST/Decl.cpp, simplify by always setting isMutating to true for
ctors/dtors, since mutability only means something to struct/enum
methods anyway.
- in DeclContext.cpp, continue to lvalue qualify the 'self' of protocol
methods, this is currently dead.
- in CSApply, fix logic for some value-type member processing stuff
to properly handle methods that have a self which is not lvalue
qualified. Not exercised yet.
Swift SVN r11650
property and subscript getters which have no explicit FuncDecl for
the getter. I'm not exactly sure where these come from, but they
look like something the clang importer is producing in some cases.
Swift SVN r11642
properties are represented as rvalues, not non-mutable lvalues. As part of
this, isReferencedAsLValue() only returns true for mutable VarDecls.
This required some pretty serious rearrangement and refactoring of code,
because now (among other things) get-only properties can be emitted as rvalues,
so the rvalue machinery needs to be able to produce getter calls.
This is an important step towards getting proper value semantics going (for
'let's etc) and also allows us to materialize addresses less often. As a
simple example, before we would silgen this:
struct S {
var i : Int
}
var P : S { get: ... }
func f() {
print(P.i)
}
into:
%2 = function_ref @_TF1tg1PVS_1S : $@thin () -> S // user: %3
%3 = apply %2() : $@thin () -> S // user: %5
%4 = alloc_stack $S // users: %9, %6, %5
store %3 to %4#1 : $*S // id: %5
%6 = struct_element_addr %4#1 : $*S, #i // user: %7
%7 = load %6 : $*Int64 // user: %8
now we generate:
%2 = function_ref @_TF1tg1PVS_1S : $@thin () -> S // user: %3
%3 = apply %2() : $@thin () -> S // user: %4
%4 = struct_extract %3 : $S, #i // user: %5
Swift SVN r11632
(various) FunctionType::get's, ArrayType::get,
ArraySliceType::get, OptionalType::get, and a few
other places.
There is more to be done here, but this is all I plan to do
for now.
Swift SVN r11497
typealias MyInt: ForwardIndex = Int
There is no real reason to allow this; it's just a static_assert that Int
conforms to ForwardIndex, which would be better spelled some other way.
This only applies to concrete typealiases, i.e. those that simply alias an
underlying type. Associated types can still have both inheritance clauses
and a (default) underlying type.
Swift SVN r11481
- Switch @mutable to be a tri-state attribute that is invertable with @!mutable.
- Move the semantic form of 'mutable' to being a bit on FuncDecl instead of
something in DeclAttrs. The former is a binary bit, the later is a tristate
which differentiates between "not present", "present and set" "present and inverted".
- Diagnose some invalid uses of @mutable, e.g. on class methods.
- Make setters default to mutable, and allow them to be switched with @!mutable.
Swift SVN r11439
This removes an oddity in the AST whereby the 'self' declaration
within a value type constructor was not represented as @inout, despite
having @inout semantics in the language.
Swift SVN r11194
- change SILGenFunction to use Cleanup and Implicit return locations for
auto-generated cleanups/returns where sensible.
- Fix a bug in where ConstructorDecl that would return the wrong
source range.
- Move the expected locations of some errors to the end of the function
where they should belong.
Fixes <rdar://problem/15609768> Line tables for classes that don't have
init but just initialize ivars are odd
Swift SVN r11086
Part of the FileUnit restructuring. A Clang module (whether from a framework
or a simple collection of headers) is now imported as a TranslationUnit
containing a single ClangModuleUnit.
One wrinkle in all this is that Swift very much wants to do searches on a
per-module basis, but Clang can only do lookups across the entire
TranslationUnit. Unless and until we get a better way to deal with this,
we're stuck with an inefficiency here. Previously, we used to hack around
this by ignoring the "per-module" bit and only performing one lookup into
all Clang modules, but that's not actually correct with respect to visibility.
Now, we're just taking the filtering hit for looking up a particular name,
and caching the results when we look up everything (for code completion).
This isn't ideal, but it doesn't seem to be costing too much in performance,
at least not right now, and it means we can get visibility correct.
In the future, it might make sense to include a ClangModuleUnit alongside a
SerializedASTFile for adapter modules, rather than having two separate
modules with the same name. I haven't really thought through this yet, though.
Swift SVN r10834
Part of the FileUnit restructuring. A serialized module is now represented as
a TranslationUnit containing a single SerializedASTFile.
As part of this change, the FileUnit interface has been made virtual, rather
than switching on the Kind in every accessor. We think the operations
performed on files are sufficiently high-level that this shouldn't affect us.
A nice side effect of all this is that we now properly model the visibility
of modules imported into source files. Previously, we would always consider
the top-level imports of all files within a target, whether re-exported or
not.
We may still end up wanting to distinguish properties of a complete Swift
module file from a partial AST file, but we can do that within
SerializedModuleLoader.
Swift SVN r10832
Build the getter and setter of a static property as static func decls, and add a verifier check that the static-ness of a var and its accessors match up.
Swift SVN r10395
Introduced VarDecl::getTypeSourceRangeForDiagnostics(), which is not precise
right now; it just highlights the type source range of the typed pattern.
Filed rdar://15441111 to improve it in future.
Swift SVN r10344
This little "find the context where the generic parameters could be"
idiom was copy-pasted in a few places, which is ugly. And if we get
generic subscripts (or some other generic value decl), we'll be sorry.
Swift SVN r9927
I tried hard find all references to 'func' in documentation, comments and
diagnostics, but I am sure that I missed a few. If you find something, please
let me know.
rdar://15346654
Swift SVN r9886
All other interface types for type declarations were already
metatypes, as they should be; this oddity crept in. Kill it before it
causes more confusion.
Swift SVN r9826
This required moving a gross hack from the old archetype-based
type-opening code over to the new, generic type parameter-based
type-opening code. We need the ability to build conformances for types
involving type variables to address this case properly.
Swift SVN r9821
Eliminate the annoying, rarely-firing "while converting 'var' initial
value to declared type" note. We'll eventually have better ways to
deal with this. Otherwise, no functionality change.
Swift SVN r9677
When the type checker sees a reference to a generic non-member
function, open its interface type, which is expressed as a
GenericFunctionType, rather than its PolymorphicFunctionType. This is
a tiny step toward weaning the type checker off archetypes within the
interface.
Swift SVN r9504
