Commit Graph

21 Commits

Author SHA1 Message Date
Rintaro Ishizaki
9fc1521aeb [Macros/Parser] Attributes on MacroExpansionDecl
* Parse `#<identifier>` attribute list as a `MacroExpansionDecl`
  regardless of the position
* Diagnose whitespaces between `#` and the macro name.
* Correctly attach attributes to `MacroExpansionDecl`
* Fix `OrigDeclAttributes` to handle modifiers (use `getLocation()`
  instead of `AtLoc`.)

Type checking is a TODO

rdar://107386648
2023-05-11 12:04:35 -07:00
Richard Wei
833338f9ce [Macros] Top-level freestanding macros (#63553)
Allow freestanding macros to be used at top-level.
- Parse top-level `#…` as `MacroExpansionDecl` when we are not in scripting mode.
- Add macro expansion decls to the source lookup cache with name-driven lazy expansion. Not supporting arbitrary name yet.
- Experimental support for script mode and brace-level declaration macro expansions: When type-checking a `MacroExpansionExpr`, assign it a substitute `MacroExpansionDecl` if the macro reference resolves to a declaration macro. This doesn’t work quite fully yet and will be enabled in a future fix.
2023-03-06 07:15:20 -08:00
Suyash Srijan
8e81a80e25 [Parse] Fix a crash when there is nothing after the prefix/postfix operator colon (#60939) 2022-09-06 21:01:42 +01:00
Becca Royal-Gordon
627ecbdfff Rip designated types out of the AST
Designated types were removed from the constraint solver in #34315, but they are currently still represented in the AST and fully checked. This change removes them as completely as possible without breaking source compatibility (mainly with old swiftinterfaces) or changing the SwiftSyntax tree. Designated types are still parsed, but they are dropped immediately and a warning is diagnosed. During decl checking we also still check if the precedence group is really a designated type, but only so that we can diagnose a warning and fall back to DefaultPrecedence.

This change also fixes an apparent bug in the parser where we did not diagnose operator declarations that contained a `:` followed by a non-identifier token.
2021-08-03 16:13:59 -07:00
Anthony Latsis
a11cc4fcfc Handle more built-in operators and error intersections with the unwrap collision diagnostic 2020-02-22 03:55:43 +03:00
Anthony Latsis
1c0c397214 [Parse] Improve recovery from and diagnostics for invalid operator names 2020-02-20 22:11:18 +03:00
Mark Lacey
039d10b709 Add support for parsing designated protocols in operator declarations.
The support is gated by a frontend option,
-enable-operator-designated-protocols.

This means that in an operator declaration we can declare a protocol
which has one or more requirements specifying this operator. The
operators from that designated protocol will be the first ones we try
when type checking an expression. If we successfully typecheck using
the operators specified in that protocol, we do not attempt any other
overloads of the same operator.

This makes it possible to dramatically speed up successful
typechecking.
2018-09-05 11:58:43 -07:00
Robert Widmann
cacc5ca863 Migrate Parse and NameBinding tests 2018-06-27 13:22:25 -07:00
Slava Pestov
5d2752f7d2 Run tests with -swift-version 4 by default
Some test now fail, so add an explicit -swift-version 3.
2018-06-19 23:24:19 -07:00
David Farler
b7d17b25ba Rename -parse flag to -typecheck
A parse-only option is needed for parse performance tracking and the
current option also includes semantic analysis.
2016-11-28 10:50:55 -08:00
gregomni
dc239af995 The existing limitation that postfix operators can't begin with '?' or '!'
wasn't being detected while parsing operator decls, and so declarations of
invalid operators would be accepted without error and then later couldn't
be used.

Now errors correctly and new tests added.
2016-10-13 20:40:10 -07:00
Jacob Bandes-Storch
d6590cd781 [QoI] improve diagnostics for operator declarations; unify parsing code 2016-09-04 22:17:29 -07:00
Jordan Rose
3d005f3ad9 [Parse] Add fix-its for empty Swift 2 operator decl braces. (#4309)
And improve the error message for non-empty braces; if we're going to
ignore the contents, we should at least point you in the right
direction for Swift 3.

rdar://problem/27576922
2016-08-15 14:43:09 -07:00
John McCall
c8c41b385c Implement SE-0077: precedence group declarations.
What I've implemented here deviates from the current proposal text
in the following ways:

- I had to introduce a FunctionArrowPrecedence to capture the parsing
  of -> in expression contexts.

- I found it convenient to continue to model the assignment property
  explicitly.

- The comparison and casting operators have historically been
  non-associative; I have chosen to preserve that, since I don't
  think this proposal intended to change it.

- This uses the precedence group names and higherThan/lowerThan
  as agreed in discussion.
2016-07-26 14:04:57 -07:00
Chris Willmore
690daa539a Back out changes for in-place methods/operators from Xcode 7.
This reverts commits r26508, r26545, and r26576.

Swift SVN r26900
2015-04-02 21:14:28 +00:00
Chris Willmore
1ee6f7e67c Implement syntax changes for in-place methods.
Rename 'assignment' attribute of infix operators to 'mutating'. Add
'has_assignment' attribute, which results in an implicit declaration of
the assignment version of the same operator. Parse "func =foo"
declaration and "foo.=bar" expression. Validate some basic properties of
in-place methods.

Not yet implemented: automatic generation of wrapper for =foo() if foo()
is implemented, or vice versa; likewise for operators.

Swift SVN r26508
2015-03-25 00:22:41 +00:00
Dmitri Hrybenko
3b04d1b013 tests: reorganize tests so that they actually use the target platform
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK.  The driver was defaulting to the
host OS.  Thus, we could not run the tests when the standard library was
not built for OS X.

Swift SVN r24504
2015-01-19 06:52:49 +00:00
Joe Groff
7feeecfd21 Sema: Bring back 'assignment' as an infix operator modifier.
We need it to decide whether to admit infix operators into an optional chain, such as 'x? = 0' or 'x?.y += 2'.

Swift SVN r20295
2014-07-22 05:16:01 +00:00
Chris Lattner
57cd2506ff Change "operator infix" to "infix operator" for consistency with the rest of the declaration
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
2014-07-14 16:39:10 +00:00
Ted Kremenek
fad874708e Adjust test cases.
Swift SVN r17964
2014-05-12 22:01:52 +00:00
Joe Groff
aeeda4ee12 Parser: Parse operator decls.
At the top level, if 'operator' is followed by 'infix', 'prefix', or 'postfix', consider it a contextual keyword, and parse an operator decl following it that looks like:

  operator {infix|postfix|prefix} <+> {
    attributes…
  }

Prefix and postfix operator decls currently admit no attributes. Infix operators have 'associativity {left|right|none}' and 'precedence <int>' attributes.

This patch implements parsing for operator declarations but does not yet attach the declared attributes to func decls for the operators.

Swift SVN r4596
2013-04-03 23:30:50 +00:00