We parse 'try' as if it were a unary operator allowed on an
arbitrary element of an expr-sequence, but sequence-folding
constrains it to never appear on the RHS of most operators.
We do allow it on the RHS of an assignment or conditional
operator, but not if there's anything to the right which
was not parsed within the RHS.
We do this for assignments so that
var x = try whatever
and
x = try whatever
both work as you might expect.
We do this for conditionals because it feels natural to
allow 'try' in the center operand, and then disallowing it
in the right operand feels very strange.
In both case, this works largely because these operators are
assumed to be very low-precedence; there are no standard
operators which would parse outside the RHS. But if you
create one and use 'try' before it, we'll diagnose it.
Swift SVN r26052
Make this diagnostic a little nicer in other ways, too:
- Highlight the whole attribute (including the at-sign).
- Don't hardcode the string "objc".
Swift SVN r25999
auto-completing @attributes. By delaying the handling of code completion token after the entire decl being parsed, we know
what are the targets of the attribute to finishe, thus, only suggesting those applicable attributes.
Swift SVN r25938
This introduces a new pattern, spelled "x?" which is sugar for
matching ".Some(x)". It also changes the parser slightly so that
_ (the discard expr) is parsed as a unary expr instead of as an
expr. This allows it to have postfix ? after it, which is important
in pattern contexts to support "case _?:".
Swift SVN r25907
context-sensitive. The first step is to recommend parameter-applicable
attributes only when the code completion token is found inside a
param decl.
Swift SVN r25810
This doesn't allow 'continue' out of an if statement for the same reason we don't
allow it on switch: we'd prefer people to write loops more explicitly.
Swift SVN r25565
Previously, adding observing accessors to a variable caused it to require
an explicit type /and/ an initializer. Now you just need one or the other;
the type of the accessors is drawn from the type of the VarDecl, whether
inferred or explicitly written.
rdar://problem/18148072
Swift SVN r24664
rdar://problem/17198298
- Allow 'static' in protocol property and func requirements, but not 'class'.
- Allow 'static' methods in classes - they are 'class final'.
- Only allow 'class' methods in classes (or extensions of classes)
- Remove now unneeded diagnostics related to finding 'static' in previously banned places.
- Update relevant diagnostics to make the new rules clear.
Swift SVN r24260
SILMetadata is the base class with a single enum member (MDKind).
SILBranchNode is the derived class with additional members:
unsigned NumOperands
an array of uint32_t
A static member function SILBranchNode::get is implemented to get or create
SILBranchNode. All SILMetadata created are uniqued and saved in SILModule's
member variable:
llvm::FoldingSet<SILMetadata> Metadatas
Usage of SILMetadta by SILInstruction is captured in SILModule's member variable:
llvm::DenseMap<const SILInstruction *, SILMetadata *> MetadataStore
This is similar to LLVM's Metadata. Another option is to add a SILMetadata* to
SILInstruction. The disadvantage is the waste of space when we don't have PGO on.
This commit also enables parsing and printing of SILMetadata.
We add keyword sil_metadata to define SILMetadata:
sil_metadata !0 = {"branch_weights", 3, 5}
For parsing, we add a map in SILModule
llvm::DenseMap<unsigned, SILMetadata *> NumberedMetadata
that maps from ID to SILMetadata* to help matching usage of "!id" in SILFunction
with definition of "!id" in sil_metadata section.
For printing, we assign IDs to SILMetadata at SILModule scope, we then pass in
an optional argument of
llvm::DenseMap<const SILMetadata *, unsigned> *MetadataMap
to SILFunction::print in order to get the ID of SILMetadata used in
SILInstruction.
Post-commit review will be appreciated.
rdar://18269754
Swift SVN r23713
Use the same token-splitting technique we use to interpret '>>>' as a series of closing angle brackets to also extract '?' and '!' IUO sigils. Tweak it so that we properly reset the lexer state instead of just peeking the next token, because otherwise, when we chop a token like '>?>>', we'll see only the '?' (because '?' by itself is a question_postfix) and drop the '>>' on the floor. Remove the lexer hacks that pattern-matched specific >?>? sequences.
Swift SVN r22669
llvm::Optional lives in "llvm/ADT/Optional.h". Like Clang, we can get
Optional in the 'swift' namespace by including "swift/Basic/LLVM.h".
We're now fully switched over to llvm::Optional!
Swift SVN r22477
This patch adds a new 'pound_os' token, a new case for it in parseExprPostfix, and parsing of platform version constraints, e.g., OSX >= 10.10.
It also adds enough type checking and SILGen to get the parsing tests to run without triggering "Unimplemented" assertions.
Swift SVN r21865
-Previously the range would include the right brace of the computed variable but not the left one
-Incomplete implicit getter would trigger assertion in the AST verifier.
rdar://18189904
Swift SVN r21659
This moves a crude parser check for stored properties in enums & extensions into Sema, and changes it
to be correct (rejecting the case that caused the crash in the radar) as well as more descriptive.
Swift SVN r20695
As part of this change, allow #line directives to extend to the end of the
file, rather than requiring a reset.
Note that #line regions that start or end within function bodies will not
behave correctly when in delayed parsing modes. This was true before and
after this commit. (#line regions contained entirely within a function and
not within any other #line regions should be fine.)
Swift SVN r20571
Before this commit, we were not able to differentiate between stored
property and stored_with_trivial_accessors property. This causes issues
when parsing a SILDeclRef to a trivial getter.
We add @sil_stored for stored properties and we will have 3 cases
A) for stored property: @sil_storage var x : Int
B) for stored_with_trivial_accessors property:
@sil_storage var x : Int { get set }
C) for computed property: var x : Int { get set }
Fix rdar://17715778 rdar://17381432 rdar://17347296.
Swift SVN r20189
attribute. As part of this, introduce a new "NotSerialized" flag in Attr.def.
This eliminates a bunch of special case code in the parser and elsewhere for handling
this modifier.
Swift SVN r19997
to operator decls, and validate the attributes in the type checker. This allows
us to reject invalid operator decls (resolving a fixme) and restores syntax coloring
of 'infix' on an operator (a regression in my last patch).
Swift SVN r19932
modifiers and with the func implementations of the operators. This resolves the rest of:
<rdar://problem/17527000> change operator declarations from "operator prefix" to "prefix operator" & make operator a keyword
Swift SVN r19931
This only tackles the protocol case (<rdar://problem/17510790>); it
does not yet generalize to an arbitrary "class" requirement on either
existentials or generics.
Swift SVN r19896
- Change the parser to accept "objc" without an @ sign as a contextual
keyword, including the dance to handle the general parenthesized case.
- Update all comments to refer to "objc" instead of "@objc".
- Update all diagnostics accordingly.
- Update all tests that fail due to the diagnostics change.
- Switch the stdlib to use the new syntax.
This does not switch all tests to use the new syntax, nor does it warn about
the old syntax yet. That will be forthcoming. Also, this needs a bit of
refactoring, which will be coming up.
Swift SVN r19555
This patch extends the syntax with a new #line directive that is inspired
by the homonymous CPP directive. It can be specified in all locations a #if
is legal (Stmt, Decl).
Semantics
---------
#line 42 "file.swift"
This makes diagnostics and debug information behave as if the subsequent
lines came from file.swift+42.
#line // without arguments
This switches back to the main source file and the switches back to the
normal line numbering. Any previous #line directives will result in gaps
in the main file.
Rationale
---------
LLDB and the REPL need this for making expressions that are entered into
the expression evaluator or REPL debugable. For more info see
<rdar://problem/17441710> Need #line directive or something similar so we can enhance the debugging of expressions and REPL
Also, I believe the stdlib would benefit from this and it would allow us
to get rid of the line-directive wrapper script.
Swift SVN r19384
Handle parsing of dictionary type sugar into its own type
representation, including both type and expression contexts.
This is the first part of <rdar://problem/17460972>; we still need a
sugared Type node.
Swift SVN r19239
