Open RyanGlScott opened 10 months ago
Thanks for reporting these. There's been no effort to make sure that the pretty-printer for an entire BSV file will read back in correctly and identically, so I am not surprised if you find issues like this. The only concern was the printing of any snippets that appear in error messages to the user, which are usually just types, or IDs, or individual method calls. The -d
dump flags were considered hidden features for developers, and they didn't need to be perfect (and could change or disappear at any time). But it's a good aim to have the pretty-printer work for full programs, so thank you for reporting this.
The module type should be preserved. I assume that this is just a bug in CVPrint.hs
, probably around line 165, in the function p2defs
:
line1 = t"module" <+> pvpId d i <> f ys <> t"(" <> pvPrint d 0 ity <> t")"
Thanks! And I certainly don't expect the pretty-printer to be 100% accurate in all cases. My use case is that I am generating very simple BSV code programmatically using the bsc
source code, and I ran into some situations where even very simple code fails to parse when fed back into bsc
. My goal is to fix only those issues that I encounter when pretty-printing the very limited subset of BSV that I'm generating.
I'll give CVPrint
a closer look. For posterity's sake, here is a permalink to the code mentioned in https://github.com/B-Lang-org/bsc/issues/663#issuecomment-1897040650:
Given this BSV code:
Compiling it with
bsc -dparsed=FooParsed.bsv Foo.bsv
yields:This is almost the same code, but there is one key difference: the
module
keyword lacks the[Module]
part after it. This change is significant enough to cause bsc to reject it:Any reason not to preserve the
[Module]
part?