Skip to content
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

[line breaks, wraps] Multiline parameter break tuning #33

Open
msfschaffner opened this issue Nov 25, 2019 · 3 comments
Open

[line breaks, wraps] Multiline parameter break tuning #33

msfschaffner opened this issue Nov 25, 2019 · 3 comments
Labels
formatter Verilog code formatter issues

Comments

@msfschaffner
Copy link

should:

parameter exception_cause_t implemented_exception[] = {INSTRUCTION_ACCESS_FAULT, 
                                                       ILLEGAL_INSTRUCTION, BREAKPOINT,
                                                       LOAD_ACCESS_FAULT, STORE_AMO_ACCESS_FAULT, 
                                                       ECALL_MMODE};

is:

parameter exception_cause_t
    implemented_exception[] = {INSTRUCTION_ACCESS_FAULT, ILLEGAL_INSTRUCTION, BREAKPOINT,
                               LOAD_ACCESS_FAULT, STORE_AMO_ACCESS_FAULT, ECALL_MMODE};

Note that this "compact" enumeration style is different than from the "long list style" mentioned in #32

@fangism fangism added the formatter Verilog code formatter issues label Nov 26, 2019
@fangism
Copy link
Collaborator

fangism commented Nov 26, 2019

This look like a case that deferred to the wrap-optimizer, which is currently subject to zero-effort penalty tuning. We should be able to achieve the form you desire with better penalty values. Will categorize as such.

How amenable would you be to:

parameter foo_t bar[] = {
  value,
  value,
  ...
};

or

parameter foo_t bar[] = {
  value, value,
  ...
};

@fangism fangism added this to penalty tuning in SV formatter Nov 26, 2019
@msfschaffner
Copy link
Author

So your first example would basically correspond to the "long list style" in #32, right? I am actually fine with both styles that you suggested. is it possible to support both of them? I.e. variant 1) for long lists and 2) for short ones? or should we distinguish the two cases by adding inline // blockers if we desire style 1), and default to 2) otherwise?

@msfschaffner
Copy link
Author

b/145161192

hzeller pushed a commit that referenced this issue Feb 6, 2020
  Given a left and right token, and their respective contexts (stacks),
  the new factor is computed: (let a, b, c,... be syntax tree node enums)

  left : [a, b, c, d, e, f, g, h]
  right: [a, b, c, d, p, q, r, s, t]

  The common ancestry C is 4.
  The penalty factor is scaled linearly: C * k (currently, k=2)

This attempts to very quickly give not-horrible results when wrapping
long and deep structures.

This will serve as a baseline for subsequent penalty tunings.

issues #30, #33, #36

PiperOrigin-RevId: 293466087
nikhiljha pushed a commit to nikhiljha/verible that referenced this issue Sep 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
formatter Verilog code formatter issues
Projects
SV formatter
penalty tuning
Development

No branches or pull requests

2 participants