Remove dead code in crout

[JCGoran]

The if (0) part should never execute. For reference, the first occurrence of it seems to be this commit: d5d03af

[sonarcloud]

Quality Gate passed

Issues
1 New issue
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud

[azure-pipelines]

✔️ b20be94 -> Azure artifacts URL

[bbpbuildbot]

Logfiles from GitLab pipeline #228419 (:white_check_mark:) have been uploaded here!

Status and direct links:

• ✅ mac_m1_cmake_build: [cmake, ON, OFF, OFF, address]
• ✅ spack_setup
• ✅ build:nmodl
• ✅ build:neuron:nmodl:intel:legacy
• ✅ build:neuron:nmodl:intel:shared
• ✅ build:neuron:nmodl:nvhpc:acc:legacy
• ✅ build:neuron:nmodl:nvhpc:acc:shared
• ✅ build:neuron:nmodl:nvhpc:omp:legacy
• ✅ build:neuron:nmodl:nvhpc:omp
• ✅ test:neuron:nmodl:intel:legacy
• ✅ test:neuron:nmodl:intel:shared
• ✅ test:neuron:nmodl:nvhpc:acc:legacy
• ✅ test:neuron:nmodl:nvhpc:acc:shared
• ✅ test:neuron:nmodl:nvhpc:omp:legacy
• ✅ test:neuron:nmodl:nvhpc:omp

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 67.26%. Comparing base (4844029) to head (b20be94).
Report is 1 commits behind head on master.

Additional details and impacted files

@@           Coverage Diff           @@
##           master    #3060   +/-   ##
=======================================
  Coverage   67.26%   67.26%           
=======================================
  Files         571      571           
  Lines      104885   104887    +2     
=======================================
+ Hits        70550    70552    +2     
  Misses      34335    34335           

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

[1uc]

I'm not opposed to cleaning this up. However, a disadvantage of removing the upper branch is that now the function is strange in that it kinda pretends that it has certain permutation functionality (via y) when in fact the implementation makes to attempt at supporting that case.

The existing has the advantage that it shows what should be happening if y where passed in. However, it misleads us to believe that ignoring y is fine.

I feel this is a place where commenting the code might help. Something that explains that y is never used and must be a nullptr, but the fact can't be asserted, because when using pgacc, the pointer is spuriously non-null.

Or one could continue one step further and remove the argument y from the function signature.

[1uc]

Suggested change

	int* y,
	int* /* y */,

given the large number of macros, it's very hard to know if y is really used or not.

[1uc]

I can't figure out what these sentences what to convey. Maybe they should be updated along with the doc string of the function.