-
Notifications
You must be signed in to change notification settings - Fork 143
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
uppercase names not allowed in interface property arg_names
#654
Comments
The datatype and the Classic parsing were added in 2005 and remained mostly unchanged. The comments on the datatype look wrong, as if they were for an earlier iteration than what we see, so it's possible that the checked-in code has other aspects (like the choice of As you say, some digging is needed to see if the position information is used. (I think that GenWrap uses the names, possibly when creating the wrapper, so if there was ever an error message on that code, it would point to the name in the interface declaration.) I think it's OK for the type to be |
good point, i always forget that things are sometimes fwiw, i'm not sure autoescaping from (say) |
Be careful: Currently, if the user does want a name containing non-standard characters, there's no way to write it. And BSC doesn't consistently report an error about bad characters in the identifier. If I specify I also notice that I can put a |
right, initial either way i suspect using escaped names in "native" verilog is rare, so either way works really. of course there should me more error checking (also applies to some classic ids that are not valid verilog ids, although maybe escaping already happens there). |
the
arg_names
property of interface fields does not allow names starting with uppercase:this is the error:
it seems that the parser thinks that
FOOBAR
is a package name, and expect it to start a qualified identifier. and indeed the relevant fragment ofCParser.hs
usespFieldId
for this:but of course things with dots don't make sense to generate as a Verilog identifier, and if you replace
FOO
withFOO.bar
then the compiler indeed rightfully complains about this:interestingly
PIArgNames
takes[Id]
whereas all other properties takeString
; not sure why it's not[String]
but perhaps there is some deep reason somewhere?The text was updated successfully, but these errors were encountered: