Skip to content

Unexpected behavior with indentation #9790

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
tgodzik opened this issue Sep 14, 2020 · 4 comments
Closed

Unexpected behavior with indentation #9790

tgodzik opened this issue Sep 14, 2020 · 4 comments

Comments

@tgodzik
Copy link
Contributor

tgodzik commented Sep 14, 2020

Minimized code

A sample like this compiles fine:

object A:
   def fn: Unit =
    if true then
  println(1)
    else
  println(2)

but this one does not:

object A:
   def fn: Unit =
    if true then
  println(1)
  println(1)
    else
  println(2)

This is most likely due to one being a single statement and the other one is treated as a block, but this is a bit of an incoherent behavior and could lead to hard to spot errors.

Expectation

Then should require a proper increasing indentation and both examples should fail.

@odersky
Copy link
Contributor

odersky commented Sep 20, 2020

I believe this is all as expected and specified. Surprising? Maybe, but it can be explained by the stated rules.
You get for the second example:

-- Error: test.scala:5:2 -------------------------------------------------------
5 |  println(1)
  |  ^
  |The start of this line does not match any of the previous indentation widths.
  |Indentation width of current line : 2 spaces
  |This falls between previous widths: 0 spaces and 3 spaces
1 error found

(that's the second println(1) line that is flagged). This is exactly as intended. The first println(1) line is a part of the if statement. It does not start a new indentation region since it is not indented relative to the if. So the second println(1) line
is a new statement, following the if, but indented towards its left.

@odersky odersky closed this as completed Sep 20, 2020
@smarter
Copy link
Member

smarter commented Sep 20, 2020

The first println(1) line is a part of the if statement. It does not start a new indentation region since it is not indented relative to the if

But couldn't we flag as an error the fact that it's indented less than the if it's part of?

@tgodzik
Copy link
Contributor Author

tgodzik commented Sep 21, 2020

The first println(1) line is a part of the if statement. It does not start a new indentation region since it is not indented relative to the if

But couldn't we flag as an error the fact that it's indented less than the if it's part of?

Or at least a warning. With then we can be pretty sure that the user wanted indentation, so the fact that this code works is kind of misleading. We should avoid having weird indention issues, which for people coming for example from python would be hard to understand. It should not require looking into the docs to see why this is happening.

@tgodzik
Copy link
Contributor Author

tgodzik commented Sep 28, 2020

Sorry for getting back to it, but after thinking about it further. When it comes to:

object A:
   def fn: Unit =
    if true then
  println(1)
    else
  println(2)

The rule states:

An <outdent> is inserted at a line break, if

the first token on the next line has an indentation width strictly less than the current indentation width, and
the first token on the next line is not a leading infix operator.

So outdent for function fn should be added before println(1), however somehow it is not in case of the Dotty parser. I am confused about thus behavior, how is the stated rule modified after for example then ?

@odersky @smarter any idea?

We are having some issues with https://github.com/scalameta/scalameta/pull/2104/files so any additional information would be useful.

@tgodzik tgodzik reopened this Sep 28, 2020
odersky added a commit that referenced this issue Nov 16, 2020
Fix #9790: Update indentation spec to match observed behavior
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants