appears in a deprecated context. In the new strategy, we emit the warnings
as usual unless we're currently parsing a declaration, where "declaration" is
restricted to mean a decl group or a few special cases in Objective C. If
we *are* parsing a declaration, we queue up the deprecation warnings until
the declaration has been completely parsed, and then emit them only if the
decl is not deprecated.
We also standardize the bookkeeping for deprecation so as to avoid special cases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85998 91177308-0d34-0410-b5e6-96231b3b80d8
yet another copy of the unqualified-id parsing code.
Also, use UnqualifiedId to simplify the Action interface for building
id-expressions. ActOnIdentifierExpr, ActOnCXXOperatorFunctionIdExpr,
ActOnCXXConversionFunctionExpr, and ActOnTemplateIdExpr have all been
removed in favor of the new ActOnIdExpression action.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85904 91177308-0d34-0410-b5e6-96231b3b80d8
representation of a C++ unqualified-id, along with a single parsing
function (Parser::ParseUnqualifiedId) that will parse all of the
various forms of unqualified-id in C++.
Replace the representation of the declarator name in Declarator with
the new UnqualifiedId class, simplifying declarator-id parsing
considerably and providing more source-location information to
Sema. In the future, I hope to migrate all of the other
unqualified-id-parsing code over to this single representation, then
begin to merge actions that are currently only different because we
didn't have a unqualified notion of the name in the parser.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85851 91177308-0d34-0410-b5e6-96231b3b80d8
types. Preserve it through template instantiation. Preserve it through PCH,
although TSTs themselves aren't serializable, so that's pretty much meaningless.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85500 91177308-0d34-0410-b5e6-96231b3b80d8
which should come from the variable and wasn't correct for arrays in any case.
No change in functionality.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85415 91177308-0d34-0410-b5e6-96231b3b80d8
process decl attributes instead of dropping them on the floor.
This allows us to diagnose cases like the testcase. Also don't
diagnose deprecated stuff in ActOnTag: not all uses of tags
may be 'uses', and SemaType does this now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85071 91177308-0d34-0410-b5e6-96231b3b80d8
types) out of Sema::getTypeName into ConvertDeclSpecToType. getTypeName
is sometimes used as a predicate in the parser, so it could cause redundant
diags to be emitted. This is also needed by two upcoming enhancements.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85070 91177308-0d34-0410-b5e6-96231b3b80d8
IIDecl cannot be null. There is no need to check for both C++ mode and
presence of CXXRecordDecl. ObjC interfaces can't have ScopeSpecs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85057 91177308-0d34-0410-b5e6-96231b3b80d8
type looking using getTypeName() and every property access was using
NextToken() to do lookahead to see if the identifier is followed by
a '.'. Rearrange this code to not need lookahead and only do the
type lookup if we have "identifier." in the token stream. Also
improve a diagnostic a bit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@85056 91177308-0d34-0410-b5e6-96231b3b80d8
template instantiation. Preserve it through PCH. Show it off to the indexer.
I'm healthily ignoring the vector type cases because we don't have a sensible
TypeLoc implementation for them anyway.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84994 91177308-0d34-0410-b5e6-96231b3b80d8
in the DeclaratorInfo, if one is present.
Preserve source information through template instantiation. This is made
more complicated by the possibility that ParmVarDecls don't have DIs, which
is possibly worth fixing in the future.
Also preserve source information for function parameters in ObjC method
declarations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84971 91177308-0d34-0410-b5e6-96231b3b80d8
to all callers. Switch a few other users of CK_Unknown to proper cast
kinds.
Note that there are still some situations where we end up with
CK_Unknown; they're pretty easy to find with grep. There
are still a few missing conversion kinds, specifically
pointer/int/float->bool and the various combinations of real/complex
float/int->real/complex float/int.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84623 91177308-0d34-0410-b5e6-96231b3b80d8
TypeLoc records for declarations; it should not be necessary to represent it
directly in the type system.
Please complain if you were using these classes and feel you can't replicate
previous functionality using the TypeLoc API.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84222 91177308-0d34-0410-b5e6-96231b3b80d8
unknown type name, e.g.,
foo::bar x;
when "bar" does not refer to a type in "foo".
With this change, the parser now calls into the action to perform
diagnostics and can try to recover by substituting in an appropriate
type. For example, this allows us to easily diagnose some missing
"typename" specifiers, which we now do:
test/SemaCXX/unknown-type-name.cpp:29:1: error: missing 'typename'
prior to dependent type name 'A<T>::type'
A<T>::type A<T>::f() { return type(); }
^~~~~~~~~~
typename
Fixes PR3990.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84053 91177308-0d34-0410-b5e6-96231b3b80d8
what we found when we looked into <blah>", where <blah> is a
DeclContext*. We can now format DeclContext*'s in nice ways, e.g.,
"namespace N", "the global namespace", "'class Foo'".
This is part of PR3990, but we're not quite there yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@84028 91177308-0d34-0410-b5e6-96231b3b80d8
template as a specialization. For example, this occurs with:
template<typename T>
struct X {
template<typename U> struct Inner { /* ... */ };
};
template<> template<typename T>
struct X<int>::Inner {
T member;
};
We need to treat templates that are member specializations as special
in two contexts:
- When looking for a definition of a member template, we look
through the instantiation chain until we hit the primary template
*or a member specialization*. This allows us to distinguish
between the primary "Inner" definition and the X<int>::Inner
definition, above.
- When computing all of the levels of template arguments needed to
instantiate a member template, don't add template arguments
from contexts outside of the instantiation of a member
specialization, since the user has already manually substituted
those arguments.
Fix up the existing test for p18, which was actually wrong (but we
didn't diagnose it because of our poor handling of member
specializations of templates), and add a new test for member
specializations of templates.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83974 91177308-0d34-0410-b5e6-96231b3b80d8
function templates.
This commit ensures that friend function templates are constructed as
FunctionTemplateDecls rather than partial FunctionDecls (as they
previously were). It then implements template instantiation for friend
function templates, injecting the friend function template only when
no previous declaration exists at the time of instantiation.
Oh, and make sure that explicit specialization declarations are not
friends.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83970 91177308-0d34-0410-b5e6-96231b3b80d8
that are declarations (rather than definitions). Also, be sure to set
the access specifiers properly when instantiating the declarations of
member function templates.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83911 91177308-0d34-0410-b5e6-96231b3b80d8
instantiation has already been required. To do so, keep track of the
point of instantiation for anything that can be instantiated.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83890 91177308-0d34-0410-b5e6-96231b3b80d8
Split the various ambiguous result enumerators into their own enum. Tests
for most of C++ [namespace.qual].
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83700 91177308-0d34-0410-b5e6-96231b3b80d8
Also, eliminate a redundant diagnostic by marking a variable declared
with incomplete type as an invalid declaration.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83553 91177308-0d34-0410-b5e6-96231b3b80d8
function and member function templates that are not definitions. Add
more tests to ensure that explicit specializations of member function
templates prevent instantiation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83550 91177308-0d34-0410-b5e6-96231b3b80d8
templates, and keep track of how those member classes were
instantiated or specialized.
Make sure that we don't try to instantiate an explicitly-specialized
member class of a class template, when that explicit specialization
was a declaration rather than a definition.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83547 91177308-0d34-0410-b5e6-96231b3b80d8
track of the kind of specialization or instantiation. Also, check the
scope of the specialization and ensure that a specialization
declaration without an initializer is not a definition.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83533 91177308-0d34-0410-b5e6-96231b3b80d8
templates. Previously, these weren't handled as specializations at
all. The AST for representing these as specializations is still a work
in progress.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83498 91177308-0d34-0410-b5e6-96231b3b80d8
for bases, members, overridden virtual methods, etc. The operations
isDerivedFrom and lookupInBases are now provided by CXXRecordDecl,
rather than by Sema, so that CodeGen and other clients can use them
directly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83396 91177308-0d34-0410-b5e6-96231b3b80d8
of the flow-control checks for falling off the end of a function,
since the return type may instantiate to void. Similarly, if a
return statement has an expression and the return type of the function
is void, don't complain if the expression is type-dependent, since
that type could instantiate to void.
Fixes PR5071.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@83222 91177308-0d34-0410-b5e6-96231b3b80d8
functions that occur in multiple declaration contexts, e.g., because
some were found via using declarations. Now, isDeclInScope will build
a new overload set (when needed) containing only those declarations
that are actually in scope. This eliminates a problem found with
libstdc++'s <iostream>, where the presence of using
In the longer term, I'd like to eliminate Sema::isDeclInScope in favor
of better handling of the RedeclarationOnly flag in the name-lookup
routines. That way, name lookup only returns the entities that matter,
rather than taking the current two-pass approach of producing too many
results and then filtering our the wrong results. It's not efficient,
and I'm sure that we aren't filtering everywhere we should be.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82954 91177308-0d34-0410-b5e6-96231b3b80d8
class templates. We now treat friend class templates much more like
normal class templates, except that they still get special name lookup
rules. Fixes PR5057 and eliminates a bunch of spurious diagnostics in
<iostream>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82848 91177308-0d34-0410-b5e6-96231b3b80d8
template void f<int>(int);
~~~~~~
Previously, we silently dropped the template arguments. With this
change, we now use the template arguments (when available) as the
explicitly-specified template arguments used to aid template argument
deduction for explicit template instantiations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82806 91177308-0d34-0410-b5e6-96231b3b80d8
first implementation recognizes when a function declaration is an
explicit function template specialization (based on the presence of a
template<> header), performs template argument deduction + ambiguity
resolution to determine which template is being specialized, and hooks
There are many caveats here:
- We completely and totally drop any explicitly-specified template
arguments on the floor
- We don't diagnose any of the extra semantic things that we should
diagnose.
- I haven't looked to see that we're getting the right linkage for
explicit specializations
On a happy note, this silences a bunch of errors that show up in
libstdc++'s <iostream>, although Clang still can't get through the
entire header.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82728 91177308-0d34-0410-b5e6-96231b3b80d8
Type hierarchy. Demote 'volatile' to extended-qualifier status. Audit our
use of qualifiers and fix a few places that weren't dealing with qualifiers
quite right; many more remain.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82705 91177308-0d34-0410-b5e6-96231b3b80d8
Several of the existing methods were identical to their respective
specializations, and so have been removed entirely. Several more 'leaf'
optimizations were introduced.
The getAsFoo() methods which imposed extra conditions, like
getAsObjCInterfacePointerType(), have been left in place.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@82501 91177308-0d34-0410-b5e6-96231b3b80d8
give them the appropriate exception specifications. This,
unfortunately, requires us to maintain and/or implicitly generate
handles to namespace "std" and the class "std::bad_alloc". However,
every other approach I've come up with was more hackish, and this
standard requirement itself is quite the hack.
Fixes PR4829.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81939 91177308-0d34-0410-b5e6-96231b3b80d8
generated for an inline function definition, taking into account C99
and GNU inline/extern inline semantics. This solution is simpler,
cleaner, and fixes PR4536.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81670 91177308-0d34-0410-b5e6-96231b3b80d8
of class type whose default constructor is trivial. Should un-break
testing on x86_64-pc-linux-gnu.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81405 91177308-0d34-0410-b5e6-96231b3b80d8
such initializations properly convert constructor arguments and fill
in default arguments where necessary. This also makes the ownership
model more clear.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81394 91177308-0d34-0410-b5e6-96231b3b80d8
order because it was doing so while iterating over a densemap.
There are still similar problems in other places, for example
WeakUndeclaredIdentifiers is still written to the PCH file in a nondeterminstic
order, and we emit warnings about #pragma weak in nondeterminstic order.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81236 91177308-0d34-0410-b5e6-96231b3b80d8
ways: remove elab types during desugaring, enhance pretty-printing to allow
tags to be suppressed without suppressing scopes, look through elab types
when associating a typedef name with an anonymous record type.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@81065 91177308-0d34-0410-b5e6-96231b3b80d8
of any previous declaration in case we replace it in a class's declaration table.
Fixes bug 4858. This sort of thing makes me reconsider putting friend declarations in
declaration lists.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80750 91177308-0d34-0410-b5e6-96231b3b80d8
decl list, and remove some workarounds that were due to this. Thanks to Eli for
pointing this out and providing the test case.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80745 91177308-0d34-0410-b5e6-96231b3b80d8
declarations of same, introduce a single AST class and add appropriate bits
(encoded in the namespace) for whether a decl is "real" or not. Much hackery
about previously-declared / not-previously-declared, but it's essentially
mandated by the standard that friends alter lookup, and this is at least
fairly non-intrusive.
Refactor the Sema methods specific to friends for cleaner flow and less nesting.
Incidentally solve a few bugs, but I remain confident that we can put them back.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80353 91177308-0d34-0410-b5e6-96231b3b80d8
templates within class templates, producing a member function template
of a class template specialization. If you can parse that, I'm
sorry. Example:
template<typename T>
struct X {
template<typename U> void f(T, U);
};
When we instantiate X<int>, we now instantiate the declaration
X<int>::f, which looks like this:
template<typename U> void X<int>::f(int, U);
The path this takes through
TemplateDeclInstantiator::VisitCXXMethodDecl is convoluted and
ugly, but I don't know how to improve it yet. I'm resting my hopes on
the multi-level substitution required to instantiate definitions of
nested templates, which may simplify this code as well.
More testing to come...
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80252 91177308-0d34-0410-b5e6-96231b3b80d8
TypenameType if getTypeName is looking at a member of an unknown
specialization. This allows us to properly parse class templates that
derived from type that could only otherwise be described by a typename type,
e.g.,
template<class T> struct X {};
template<typename T> struct Y : public X<T>::X { };
Fixes PR4381.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80123 91177308-0d34-0410-b5e6-96231b3b80d8
qualified name does not actually refer into a class/class
template/class template partial specialization.
Improve printing of nested-name-specifiers to eliminate redudant
qualifiers. Also, make it possible to output a nested-name-specifier
through a DiagnosticBuilder, although there are relatively few places
that will use this leeway.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80056 91177308-0d34-0410-b5e6-96231b3b80d8
their members, including member class template, member function
templates, and member classes and functions of member templates.
To actually parse the nested-name-specifiers that qualify the name of
an out-of-line definition of a member template, e.g.,
template<typename X> template<typename Y>
X Outer<X>::Inner1<Y>::foo(Y) {
return X();
}
we need to look for the template names (e.g., "Inner1") as a member of
the current instantiation (Outer<X>), even before we have entered the
scope of the current instantiation. Since we can't do this in general
(i.e., we should not be looking into all dependent
nested-name-specifiers as if they were the current instantiation), we
rely on the parser to tell us when it is parsing a declaration
specifier sequence, and, therefore, when we should consider the
current scope specifier to be a current instantiation.
Printing of complicated, dependent nested-name-specifiers may be
somewhat broken by this commit; I'll add tests for this issue and fix
the problem (if it still exists) in a subsequent commit.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80044 91177308-0d34-0410-b5e6-96231b3b80d8
accurately. Prevents the assert from triggering incorrectly when friending
functions first declared in extern "C" contexts. Fixes bug 4757.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80016 91177308-0d34-0410-b5e6-96231b3b80d8
the logic is there for out-of-line definitions with multiple levels of
nested templates, but this is still a work-in-progress: we're having
trouble determining when we should look into a dependent
nested-name-specifier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@80003 91177308-0d34-0410-b5e6-96231b3b80d8
DeclaratorDecl contains a DeclaratorInfo* to keep type source info.
Subclasses of DeclaratorDecl are FieldDecl, FunctionDecl, and VarDecl.
EnumConstantDecl still inherits from ValueDecl since it has no need for DeclaratorInfo.
Decl/Sema interfaces accept a DeclaratorInfo as parameter but no DeclaratorInfo is created yet.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@79392 91177308-0d34-0410-b5e6-96231b3b80d8
This currently breaks test/SemaObjC/id-isa-ref.m and issues some spurious warnings when you attempt to assign a struct objc_class* value to a Class variable. The test case probably should fail as it's written, because without the definition of Class the compiler should not assume struct objc_class* is a valid receiver type, but it's left broken because it would be nice if we could get that passing too for the special case of isa.
Approved by snaroff.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@79248 91177308-0d34-0410-b5e6-96231b3b80d8
FriendFunctionDecl, and create instances as appropriate.
The design of FriendFunctionDecl is still somewhat up in the air; you can
befriend arbitrary types of functions --- methods, constructors, etc. ---
and it's not clear that this representation captures that very well.
We'll have a better picture when we start consuming this data in access
control.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@78653 91177308-0d34-0410-b5e6-96231b3b80d8
This is necessary because #pragma pack and __attribute__((packed)) have different semantics. No functionality change yet, but this lays the groundwork for fixing a record layout bug.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@78483 91177308-0d34-0410-b5e6-96231b3b80d8
we were going to enter into the scope of a class template or class
template partial specialization, rebuild that type so that it can
refer to members of the current instantiation, as in code like
template<typename T>
struct X {
typedef T* pointer;
pointer data();
};
template<typename T>
typename X<T>::pointer X<T>::data() { ... }
Without rebuilding the return type of this out-of-line definition, the
canonical return type of the out-of-line definition (a TypenameType)
will not match the canonical return type of the declaration (the
canonical type of T*).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@78316 91177308-0d34-0410-b5e6-96231b3b80d8
elsewhere. Very slightly decouples DeclSpec users from knowing the exact
diagnostics to report, and makes it easier to provide different diagnostics in
some places.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@77990 91177308-0d34-0410-b5e6-96231b3b80d8
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsRecordType() -> Type::getAs<RecordType>()
Type::getAsPointerType() -> Type::getAs<PointerType>()
Type::getAsBlockPointerType() -> Type::getAs<BlockPointerType>()
Type::getAsLValueReferenceType() -> Type::getAs<LValueReferenceType>()
Type::getAsRValueReferenceType() -> Type::getAs<RValueReferenceType>()
Type::getAsMemberPointerType() -> Type::getAs<MemberPointerType>()
Type::getAsReferenceType() -> Type::getAs<ReferenceType>()
Type::getAsTagType() -> Type::getAs<TagType>()
And remove Type::getAsReferenceType(), etc.
This change is similar to one I made a couple weeks ago, but that was partly
reverted pending some additional design discussion. With Doug's pending smart
pointer changes for Types, it seemed natural to take this approach.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@77510 91177308-0d34-0410-b5e6-96231b3b80d8
and __has_trivial_constructor builtin pseudo-functions and
additionally implements __has_trivial_copy and __has_trivial_assign,
from John McCall!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@76916 91177308-0d34-0410-b5e6-96231b3b80d8
point that covers templates and non-templates. This should eliminate
the flood of warnings I introduced yesterday.
Removed the ActOnClassTemplate action, which is no longer used.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@76881 91177308-0d34-0410-b5e6-96231b3b80d8
- As it happens, this also fixes a use-of-uninitialized memory that was causing
non-deterministic test failures.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@76857 91177308-0d34-0410-b5e6-96231b3b80d8
value. This is on by default, and controlled by -Wreturn-type (-Wmost
-Wall). I believe there should be very few false positives, though
the most interesting case would be:
int() { bar(); }
when bar does:
bar() { while (1) ; }
Here, we assume functions return, unless they are marked with the
noreturn attribute. I can envision a fixit note for functions that
never return normally that don't have a noreturn attribute to add a
noreturn attribute.
If anyone spots other false positives, let me know!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@76821 91177308-0d34-0410-b5e6-96231b3b80d8
templates, e.g.,
template<typename T>
struct Outer {
struct Inner;
};
template<typename T>
struct Outer<T>::Inner {
// ...
};
Implementing this feature required some extensions to ActOnTag, which
now takes a set of template parameter lists, and is the precursor to
removing the ActOnClassTemplate function from the parser Action
interface. The reason for this approach is simple: the parser cannot
tell the difference between a class template definition and the
definition of a member of a class template; both have template
parameter lists, and semantic analysis determines what that template
parameter list means.
There is still some cleanup to do with ActOnTag and
ActOnClassTemplate. This commit provides the basic functionality we
need, however.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@76820 91177308-0d34-0410-b5e6-96231b3b80d8
Sebastian Redl
Anders Carlsson
Douglas Gregor
John McCall
Fariborz Jahanian
Mike Stump
Ted Kremenek
Chris Lattner
Eli Friedman
Daniel Dunbar
Tanya Lattner
Sanjiv Gupta
Argyrios Kyrtzidis
David Chisnall
Edward O'Callaghan
Ryan Flynn