Fixup bitshift issue on 32-bit

[nileshpatra]

Currently nmodl fails to compile on 32-bit machines with:

/<<PKGBUILDDIR>>/src/symtab/symbol_properties.hpp:217:17: warning: left shift count >= width of type [-Wshift-count-overflow]
  217 |     define = 1L << 32,
      |              ~~~^~~~~
/<<PKGBUILDDIR>>/src/symtab/symbol_properties.hpp:217:17: error: right operand of shift expression ‘(1 << 32)’ is greater than or equal to the precision 32 of the left operand [-fpermissive]
/<<PKGBUILDDIR>>/src/symtab/symbol_properties.hpp:217:20: error: enumerator value for ‘define’ is not an integer constant
  217 |     define = 1L << 32,
      |                    ^~
/<<PKGBUILDDIR>>/src/symtab/symbol_properties.hpp:220:22: warning: left shift count >= width of type [-Wshift-count-overflow]
  220 |     codegen_var = 1L << 33
      |                   ~~~^~~~~
/<<PKGBUILDDIR>>/src/symtab/symbol_properties.hpp:220:22: error: right operand of shift expression ‘(1 << 33)’ is greater than or equal to the precision 32 of the left operand [-fpermissive]
/<<PKGBUILDDIR>>/src/symtab/symbol_properties.hpp:220:25: error: enumerator value for ‘codegen_var’ is not an integer constant
  220 |     codegen_var = 1L << 33
      |                         ^~

This is an attempt to fix the same. Verified that it builds on a 32-bit chroot on v0.6.

/cc: @pramodk

[alkino]

As the underlying type is long long maybe you can use LL everywhere

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (5abaad3) 88.22% compared to head (e1317f6) 88.22%.
Report is 2 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #1143   +/-   ##
=======================================
  Coverage   88.22%   88.22%           
=======================================
  Files         175      175           
  Lines       13021    13021           
=======================================
  Hits        11488    11488           
  Misses       1533     1533           

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[alkino]

Maybe uLL or uint64_t would be better?

[pramodk]

As the underlying type is long long maybe you can use LL everywhere

➕ (i.e. in NmodlType). Otherwise, LGTM!

thanks @nileshpatra !

[nileshpatra]

As the underlying type is long long maybe you can use LL everywhere

➕ (i.e. in NmodlType). Otherwise, LGTM!

There are other interfaces as well apart fro NmodlType that use enum_type = long long. I've added LL for all such blocks. Kindly review.

[pramodk]

Maybe uLL or uint64_t would be better?

@alkino : ULL should be fine (/better?) as well. But as LL and ULL would typically be at least 64 bits, this should be Ok as well, right?

[alkino]

Right. I only find it more clear if this is U. I would advocate for ULL
Keep it like that. We can make the move in a following PR

[nileshpatra]

The Sonar CI fails with:

ERROR: Project not found. Please check the 'sonar.projectKey' and 'sonar.organization' properties, the 'SONAR_TOKEN' environment variable, or contact the project administrator

I don't think I can do anything here. Can you please do the needful?

[alkino]

The Sonar CI fails with:

ERROR: Project not found. Please check the 'sonar.projectKey' and 'sonar.organization' properties, the 'SONAR_TOKEN' environment variable, or contact the project administrator

I don't think I can do anything here. Can you please do the needful?

We take care of that, thank you for your PR. It will be merge soon or later (tomorrow).

[ohm314]

@nileshpatra, I think if you rebase your PR branch on our latest master the sonarcloud job should become non-failing.

[nileshpatra]

@nileshpatra, I think if you rebase your PR branch on our latest master the sonarcloud job should become non-failing.

Thanks it seems green now. The remaining (docs/epfl CI) probably need your approval?