Provide completion near unterminated binary operator

[radeksimko]

Context

While implementing support for operators in #320 a few edge cases concerning completion near an unterminated binary operator were discovered.

Examples:

• attr = 42 +
• attr = 42 + var.
• attr = 42 -
• attr = 42 - var.

In these cases we do not provide relevant completion because the upstream HCL parser does not report any of the above as BinaryOpExpr and nor does our recovery logic account for these edge cases

hcl-lang/decoder/candidates.go

Lines 175 to 187 in 436a15d

	// edge case: end of incomplete traversal with '.' (which parser ignores)
	endByte := attr.Expr.Range().End.Byte
	if _, ok := attr.Expr.(*hclsyntax.ScopeTraversalExpr); ok && pos.Byte-endByte == 1 {
	suspectedDotRng := hcl.Range{
	Filename: attr.Expr.Range().Filename,
	Start: attr.Expr.Range().End,
	End: pos,
	}
	b, err := d.bytesFromRange(suspectedDotRng)
	if err == nil && string(b) == "." {
	return true
	}
	}

I tried updating that recovery logic in some naive way but that broke other tests, so clearly there's more changes that need to be made to accommodate this edge case which cannot currently be isolated to just decoder.Any.CompletionAtPos(...).

Here is what I tried:

	// edge case: end of incomplete expression with characters which parser ignores
	gapRange := hcl.Range{
		Filename: attr.Range().Filename,
		Start:    attr.Expr.Range().End,
		End:      attr.Range().End,
	}
	if gapRange.Start.Byte < gapRange.End.Byte && gapRange.ContainsPos(pos) {
		return true
	}

Proposal

Revisit recovery logic to ensure that it can recover from the above snippets and equivalent (with other binary operators) and then deal with the issue inside decoder.Any.CompletionAtPos(...).