Wiki

Ticket #210 (assigned defect)

Opened 14 years ago

Last modified 11 years ago

Spaces after tabs should be allowed for implicit as well as explicit line continuation.

Reported by: nevdelap Owned by: Chuck
Priority: minor Milestone:
Component: Cobra Compiler Version: 0.8.0
Keywords: Cc:

Description

Space after tabs is not allowed in implicit line continuation and so currently requires the workaround of using explicit line continuation for vertical alignment where it needn't be.

Test case: (Note: code doesn't display as intended here. Ok copied to editor with tabs=4)

class X

	def foo(i as int, j as int) as int
		return i + j

	def main
		trace .foo(1, 2)
		trace .foo(1,
				2)
		trace .foo(1,
				   2)
test.cobra(11): error: test.cobra(11,1): error: Cannot mix tabs and
spaces in indentation. [TAB][TAB][TAB][TAB][SPACE][SPACE][SPACE]...

Attachments

line-cont-plus-spaces.patch Download (6.6 KB) - added by hopscc 11 years ago.

Change History

Changed 14 years ago by hopscc

see also ticket:112 and ticket:116

Changed 11 years ago by hopscc

Fix for line contin whitespace - treat same as explicit contin char in tokeniser but use a slightly different table than the Parser one.

Still allows back indent - perhaps we shouldnt but theres a largish number of tests that do this.

New test file and uncomment existing tests for indent that use both tabs and spaces.

Ticket:116 is closed. Think this should address whats left of ticket:112 also so it can be closed when this one is as well.

Changed 11 years ago by hopscc

Changed 11 years ago by hopscc

  • owner set to Chuck
  • status changed from new to assigned

Changed 11 years ago by Charles

In the patch, CobraTokenizer's list of continuation ops is duplicated from the parser with 3 changes:

  • Added COMMA
  • Removed GT and DOUBLE_GT

I presume the parser doesn't need the COMMA because that situation is handled elsewhere.

What is the implication of not having GT and DOUBLE_GT in the tokenizer's list? That something like < or + will work, but > will not?

Btw you don't have to repeat the class name for shared members:

# in CobraParser:
if .peek.which == 'EOL' and opToken.which in CobraParser.implicitContinuationOps 
# can be:
if .peek.which == 'EOL' and opToken.which in .implicitContinuationOps 

# in CobraTokenizer:
_implicitLineContinuation = .lastToken and .lastToken.which in CobraTokenizer.implicitContinuationOps
# can be:
_implicitLineContinuation = .lastToken and .lastToken.which in .implicitContinuationOps

Note to self: workspace-v

Changed 11 years ago by hopscc

Yah - think thats the case - Parser handles comma elsewhere, lexer check needs it explicitly ( like for continued/multiline method calls).

Right, Needed to drop GT and DOUBLE_GT from lexer list cos it gets seriously confounded with generic decls. I figured the loss of accepting lines ending in a GT-than comparison was an acceptable tradeoff for the moment.

I realise the class name on static is unnecessary but I try to write static method access via an explicit classname as an indicator/reminder that its a shared method access rather than an instance.

Note: See TracTickets for help on using tickets.