Inconsistent Brace Alignment with `phpfmt.psr2: false` for Certain Method Return Types

[ferhado]

I am experiencing a formatting inconsistency in the phpfmt formatter when the phpfmt.psr2 setting is set to false. Specifically, the formatter does not automatically align the opening braces { on the same line as the method signature for certain return types, though it maintains the brace position if manually adjusted.

Steps to Reproduce

1. Set the phpfmt.psr2 configuration to false.
2. Apply phpfmt formatting to a PHP class with methods having different return types.
3. Observe the position of the opening brace in relation to the method signatures.

Current Behavior

With phpfmt.psr2 set to false, the formatter does not automatically place the opening brace on the same line for some method return types:

class ExampleClass {
  // Not automatically formatted correctly
  public function setCreator(?User $creator): static
  {
    $this->creator = $creator;

    return $this;
  }

  // Also not automatically formatted correctly
  public function getCreatedAt(): ?\DateTimeImmutable
  {
    return $this->createdAt;
  }
}

However, if the braces are manually placed on the same line, the formatter does not move them:

class ExampleClass {
  // Manually corrected format is maintained
  public function setCreator(?User $creator): static {
    $this->creator = $creator;

    return $this;
  }
}

Expected Behavior

The formatter should automatically place the opening brace on the same line as the method signature for all methods:

class ExampleClass {
  public function setCreator(?User $creator): static {
    $this->creator = $creator;

    return $this;
  }

  public function getCreatedAt(): ?\DateTimeImmutable {
    return $this->createdAt;
  }
}

[driade]

Hi @ferhado I've checking this issue.

I understand your point, but "automatically place the opening brace on the same line", unless you ask specifically for it, shouldn't be enforced by the tool.

We may talk about creating a rule something like "CurlyOpenSameLine" you could opt in, the contrary of "PSR2CurlyOpenNextLine" which is the one causing the formating under PSR2.

Thanks for the issue and the long explanation.