False positive open_curly_linter / pipe_continuation_linter in magrittr pipelines

[AshesITR]

There is no way to make this piece of code lint-free without rewriting:

letters %>%
{ # - open_curly_linter
  tibble(
    lo = .,
    hi = toupper(.)
  )
} %>%
  mutate(row_id = row_number())

letters %>% { # - pipe_continuation_linter
  tibble(
    lo = .,
    hi = toupper(.)
  )
} %>%
  mutate(row_id = row_number())

[MichaelChirico]

Slight clarification: the trailing comment is not part of the issue:

letters %>%
{
  tibble(
    lo = .,
    hi = toupper(.)
  )
} %>%
  mutate(row_id = row_number())

also lints.

We should probably prefer to align to what styler does in this case (though it may be hard to predict if styler will change behavior in the future unless the action is tied to a specific style rule):

styler::style_text("
letters %>%
{
  tibble(
    lo = .,
    hi = toupper(.)
  )
} %>%
  mutate(row_id = row_number())
")

gives

letters %>%
  {
    tibble(
      lo = .,
      hi = toupper(.)
    )
  } %>%
  mutate(row_id = row_number())

Starting from the second option gives the same:

styler::style_text("
letters %>% {
  tibble(
    lo = .,
    hi = toupper(.)
  )
} %>%
  mutate(row_id = row_number())
")

letters %>%
  {
    tibble(
      lo = .,
      hi = toupper(.)
    )
  } %>%
  mutate(row_id = row_number())

[MichaelChirico]

Very similar to #487 (maybe the same?)

[AshesITR]

Worth considering separately for the to-be brace_linter.

[bersbersbers]

Worth considering separately for the to-be brace_linter.

This is still an issue with brace_linter as of 36a18e0, see also

lintr/R/brace_linter.R

Lines 53 to 54 in afcbdb3

	"Opening curly braces should never go on their own line and",
	"should always be followed by a new line."

[AshesITR]

Thanks for reminding me, we should add an exclusion if the preceding token is a magrittr pipe.
AFAIK base pipe doesn't support this syntax so no need to include that.

[bersbersbers]

we should add an exclusion if the preceding token is a magrittr pipe.

Adding a comma and an opening parenthesis to that exclusion would also fix #487 if I am not mistaken (but I may be!).