Introduce a library to handle user-defined operators

[DougGregor]

Introduce a library that implements the semantics of Swift user-defined operators and precedence groups. The primary operation is a "fold", which takes a sequence expression (i.e., something like a + b * c) and turns it into a structured syntax tree that reflects the relative precedence of the operators involved (here, * has higher precedence than +). This is one step beyond simple parsing that provides the necessary structure for later stages of processing of a Swift syntax tree.

There are several pieces to this new SwiftOperators library, including:

• PrecedenceGroup and Operator, which are semantic representations of precedence groups and operator declarations.
• PrecedenceGraph, which keeps track of a set of precedence groups and their relationships to each other, and is able to answer questions like "how to the precedences of two different groups compare?".
• Syntactic -> semantic translation to go from PrecedenceGroupDeclSyntax and OperatorDeclSyntax nodes to PrecedenceGroup and Operator, by walking the child syntax.
• OperatorTable, which contains a PrecedenceGraph that can be created by processing a source file to pick out the various operator and precedence-group declarations. It provides the core "fold" operation that turns a SequenceExprSyntax node into one that is fully-structured to show the order of operations.
• Prefabricated OperatorTable instances for the logical operators (&& and ||, as used in Swift #if conditions) and the Swift standard library operators (all the ones most Swift developers are used to), which can handle most Swift code.
• OperatorError, which describes the kinds of errors that can occur when handling operators, from missing precedence groups to ambiguous parses. There is a mapping from OperatorError to Diagnostic so that we can emit diagnostics for each error via the normal means.
• A new --fold-sequences option to -swift-parser-test to apply sequence folding to the input file as part of processing.

All that said, there are a few things that need to be finished before this library is ready:

• Finish remaining syntactic expressions that use operator precedence:
  • Explicit casts
  • Ternary expressions (? :)
  • Assignment expressions
  • Arrow expression (->)
• Integration in swift-parser-test via an option, so we can try this on lots more code
• Detect cycles in precedence groups
• Diagnostics for semantic errors in operator and precedence-group declarations
• Diagnostics for try that doesn't extend all the way to the right of ternary and assignment expressions
• Throwing lots and lots of code at it to make sure it works

[DougGregor]

@swift-ci please test

[ahoppen]

Doesn’t this call errorHandler twice? Once from SequenceFolder and once from here?

[DougGregor]

Yeah, the problem here is that rethrows checking cannot account for errors thrown in the visitor. I'll document this as a limitation. The real fix is something like swiftlang/swift-evolution#1271.

[DougGregor]

@ahoppen thanks for the great review! I answered a few things up front, and will go through and address the rest of your comments in the code before replying.

[ahoppen]

Reading this I initially thought that $0.flipped matched all previous checks (my brain somehow thought that ??) has higher precedence than .. Just wondering whether this would read easier as follows (I’m also not a huge fan of the 20 line expression)

Suggested change

	return try searchRelationships(
	initialGroupName: endGroupName, initialSyntax: endSyntax,
	targetGroupName: startGroupName, direction: .lowerThan,
	errorHandler: errorHandler
	) ?? searchRelationships(
	initialGroupName: startGroupName, initialSyntax: startSyntax,
	targetGroupName: endGroupName, direction: .higherThan,
	errorHandler: errorHandler
	) ?? searchRelationships(
	initialGroupName: startGroupName, initialSyntax: startSyntax,
	targetGroupName: endGroupName, direction: .lowerThan,
	errorHandler: errorHandler
	).map {
	$0.flipped
	} ?? searchRelationships(
	initialGroupName: endGroupName, initialSyntax: endSyntax,
	targetGroupName: startGroupName, direction: .higherThan,
	errorHandler: errorHandler
	).map {
	$0.flipped
	} ?? .unrelated
	if let relationship = try searchRelationships(
	initialGroupName: endGroupName, initialSyntax: endSyntax,
	targetGroupName: startGroupName, direction: .lowerThan,
	errorHandler: errorHandler
	) {
	return relationship
	} else if let relationship = try searchRelationships(
	initialGroupName: startGroupName, initialSyntax: startSyntax,
	targetGroupName: endGroupName, direction: .higherThan,
	errorHandler: errorHandler
	) {
	return relationship
	} else if let relationship = try searchRelationships(
	initialGroupName: startGroupName, initialSyntax: startSyntax,
	targetGroupName: endGroupName, direction: .lowerThan,
	errorHandler: errorHandler
	) {
	return relationship.flipped
	} else if relationship = try searchRelationships(
	initialGroupName: endGroupName, initialSyntax: endSyntax,
	targetGroupName: startGroupName, direction: .higherThan,
	errorHandler: errorHandler
	) {
	return relationship.flipped
	} else {
	return .unrelated
	}

[DougGregor]

To my eye, both look equally messy. I'd rather find a better answer, perhaps with a real data structure.

[DougGregor]

@swift-ci please test

[DougGregor]

@swift-ci please test

[DougGregor]

@swift-ci please test

[DougGregor]

@swift-ci please test

[DougGregor]

@swift-ci please test

[DougGregor]

@swift-ci please test

[DougGregor]

@swift-ci please test

[DougGregor]

@swift-ci please test