This is meant to be utilized for a narrow set of scenarios specific to dogfooding our pre-1.0 compiler, so please do not take any dependencies on this. In fact, I'll be removing this in the next milestone. (See rdar://problem/16380797.)
Also included - improve error recovery when parsing broken build configuration clauses.
Swift SVN r15694
The @objc attribute can now be provided with a name (in parentheses),
which names the corresponding entity in Objective-C. The name will
either be a selector (for anything that maps down to an Objective-C
method) or a single identifier (for classes and protocols).
The extra information is not used for anything yet.
Swift SVN r15626
For example:
@class_protocol, @objc
is now just:
@class_protocol @objc
Once we removed attribute grouping in brackets this comma separation
became vestigial. Doug and I discussed this and thought this
was a good simplification in the grammar.
This change still remains to be done for type attributes.
Swift SVN r15540
The parsing here for @availability isn't real yet; but it provides
scaffolding. Intended grammar:
@availability(*, unavailable, message="...")
@availability(*, unavailable)
@availability(ios, unavailable)
and so on.
Much of this doesn't work yet in a general way, but I wanted something
basic to work with to start with to wire up the functionality
for @availability end-to-end (at least for 'unavailable').
As part of this, extend DECL_ATTR to include whether or not an
attribute supports multiple declarations, and use this for
@availability.
Also hardwire darwin platforms, which we will need to have this
list come from somewhere. The checking could be done at parsing
or elsewhere.
Swift SVN r15491
Via preprocessor goop, Serialization.cpp generates a set of static
functions that can be used to verify if a set of attributes
can be serialized for a particular declaration.
This design forces the author of the attribute to specify up front
whether or not an attribute is supported on a given declaration
kind. We can possibly hoist this into semantic analysis as well.
These N separate functions do conceptually replace a simple
variadic template implementation. I'm fine with alternatives,
but the goal was to provide a way for the author of new
attributes to describe the requirements in one place: Attr.def.
Swift SVN r15470
Now that rvalues of ownership types are working, we just need to strip the ownership
type on the argument to setter and return value of getter.
Swift SVN r15460
This grammar change is motivated by consistency with richer
attributes we are going to add in the future, @availablity,
and seems a more scalable syntax amendable to parser recovery.
Conceptually, the values of the attribute look like a tuple of
arguments.
Swift SVN r15430
This representation is inspired by Clang's internal representation.
The current attribute representation, which is basically a union
of "stuff" in DeclAttributes, is not amendable to richer
attributes, such as @availability, that need to be implemented.
In Clang, attributes are modeled with actual objects that
encode both semantic and syntactic information (e.g., source ranges)
that facilitate richer checking, better diagnostics, and better tools.
This change is foundational for implementing @availability, but
also is a better long-term representation. As a migratory path,
it creates some duplications, with AttrKind and DeclAttrKind, the
two which should eventually become the same thing.
As part of this patch, there is some additional parser recovery
(for the new attribute representation) for duplicate attributes.
The parser now parses the entire duplicate attribute, which could
be quite complex, and then issues a diagnostic that the attribute
is a duplicate (and discarding it). This delayed diagnostic
also allows us to present ranges for the duplicate attribute, which
provides a better user experience.
Swift SVN r15365
Parse function declarations with the form
func murder inRoom(room: Int) weapon(Int) {}
where the function name ("murder") is separated from the parameter
names. This is the same style used in initializers, i.e.,
init withCString(cstr: CString) encoding(Encoding)
Swift SVN r15140
Namely, nested structs, class, enum and other protocol declarations within protocols should raise a parse error, but not crash the type checker.
Also, protocol methods may not have bodies.
The fact that we weren't catching these issues resulted in a number of crasher bugs:
rdar://problem/15811382
rdar://problem/16290458
rdar://problem/16299208
rdar://problem/16316944
Swift SVN r15093
This reverts commit r14488, since we're demoting 'type' back to a plain old identifier.
We could consider reallowing 'type' as a contextual keyword here, but from talking to Jordan he was OK with just reverting this functionality.
Swift SVN r14931
This means that we accept type attributes in a much broader
range of places where we previously required a <type>. <type>
was already a production that demanded a grammatically
unconstrained context because of all the possible continuations;
reducing the number of independent productions makes it easier
to choose one and thus not accidentally limit the range of
possible types parsed.
In particular, we want to be able to parse @unchecked T? pretty
much anywhere you can write a type.
Swift SVN r14912
This names the implicit argument "oldValue". Whether we keep implicit arguments or not
is a subject of debate, tracked by rdar://16268361.
Swift SVN r14819
Collect the identifiers for the selector pieces we parsed and use them to build a compound DeclName for the func decl. Currently this only manifests when __FUNCTION__ is used inside a selector-style function definition, where we now correctly produce the compound 'foo:bar:' name.
Swift SVN r14717
Previously this was spelled "import typealias", and that spelling will
continue to be allowed (since someone may specifically be importing a
typealias and want that to match), but now that 'type' is a keyword,
"import type" is the right way to spell the generic "import any type"
scoped import.
Swift SVN r14488
This makes the typechecker skip the decl completely, and it does not set types
on parameter patterns (not even to ErrorType). In fact, in the problematic
case the type checker can cope with the decl just fine, so don't set the
Invalid bit.
This fixes a crash in code completion when it encounters such a decl,
rdar://16132349
Swift SVN r14459
completion inside computed properties.
Adding tests for willSet/didSet uncovered some crashes while doing code
completion (see FIXMEs), and I will investigate these next.
Partially addresses rdar://15849262
Swift SVN r14338
- Respond to Doug's code review feedback
- Stop hacking around with scopes and use "emplace" to work around RAII in the inactive config case
- Limit use of StringRef on the front-end, in favor of std::string
- Use ArrayRef rather than SmallVector within IfConfigDecl
- Reorder new property declarations on BraceStmt to prevent unnecessary alignment issues
- Update ParseBraceItems to better capture top-level declarations, rather than using token lookahead
Swift SVN r14306
These changes add support for build and target configurations in the compiler.
Build and target configurations, combined with the use of #if/#else/#endif allow
for conditional compilation within declaration and statement contexts.
Build configurations can be passed into the compiler via the new '-D' flag, or
set within the LangOptions class. Target configurations are implicit, and
currently only "os" and "arch" are supported.
Swift SVN r14305
