halcompile: reject declarations that export the same HAL name

[tzuohann]

pin in float my_input is exported as component.N.my-input — underscores become dashes (comp.adoc, HALNAME).

A component that declares both x_y and x_y_ exports both as x-y. halcompile accepts it; the module then fails at loadrt:

HAL: ERROR: duplicate variable 'collide.0.x-y'
collide: rtapi_app_main: Invalid argument (-22)

check_name_ok() only compares declared names. check_hal_name() rejects the collision at the offending line and points at the HALNAME documentation. Functions are tracked separately from pins and params, which share one namespace in hal_lib.c.

Docs: NAMES section in the halcompile man page, note under the HALNAME table in comp.adoc. Tests: tests/halcompile/halname. All 133 in-tree .comp files preprocess with no new output.

Backport for 2.9: #4299.

🤖 Generated with Claude Code

[BsAtHome]

Name collisions are bad by default and fail to compile. Why is there an option for this? You should be able to check this much easier using a parallel name array for target names (which you apparently do) without complex regexes or lambdas by using a simple if name in array construct. Also note that functions have a different HAL namespace than pins/params.

Your second PR seems to be a duplicate and changes a generated (man) file that is not part of the repository. Why is this submitted twice?

[grandixximo]

Your second PR seems to be a duplicate and changes a generated (man) file that is not part of the repository. Why is this submitted twice?

It's a 2.9 backport, no .adoc there, also threw me off...

[tzuohann]

thanks. help me understand here. is this is a problem that can throw some people (amateurs using AI) off? if so and a little fix can help, I'll try to sharpen the solution. but if its not even an issue, i'll close the PR.

[grandixximo]

Name collisions are bad by default and fail to compile.

But they actually don't, I tested the claimed x_y + x_y_ on master, compiles fine, fails on loadrt...

Edit:
Unless you mean name collisions should always fail to compile, in the PR context, then agreed...

[BsAtHome]

Still, the option is useless.
When you encounter the situation, then you have an error. Either immediately at compile or afterwards at loadrt. There is no point in hiding the message. Halcompile should simply return with an error so that the build is interrupted.

[tzuohann]

Still, the option is useless. When you encounter the situation, then you have an error. Either immediately at compile or afterwards at loadrt. There is no point in hiding the message. Halcompile should simply return with an error so that the build is interrupted.

ok I think this resolved the bit of confusion I as well as @grandixximo had. so this is a little problem that should be patched. but the option of hiding it is useless. i'll resubmit removing the option to hide it. thanks @BsAtHome

[grandixximo]

Wasn't this initially showing also info that the pins you will find in hal have different names?
I think a general one liner info after compilation would suffice. if it's one line per compilation, we can also keep it in the normal build, no flag needed? probably a separate PR/discussion from the collision.

[tzuohann]

Wasn't this initially showing also info that the pins you will find in hal have different names? I think a general one liner info after compilation would suffice. if it's one line per compilation, we can also keep it in the normal build, no flag needed? probably a separate PR/discussion from the collision.

Per component: that's already what it did — one line per file with the names collapsed into it (my_input -> my-input, ...). But the build runs halcompile once per .comp, so its still 100+ lines on a full master build.

One line for the whole build: It would have to be a fixed message from src/hal/components/Submakefile, which then can't name any actual pins. Also, in-tree only, so out-of-tree authors never see it.

I have no clue how folks use this so I'll leave it to you guys to tell me what to do.

[grandixximo]

that's already what it did — one line per file with the names collapsed into it (my_input -> my-input, ...

You did do that originally, but that part has been removed, that is what I was saying, it is not there anymore, check the code...
halcompile is currently silent on success which is typical for compile tools, although it could be argued the audience of halcompile is not typical programmer audience, anyone using a compile tool should at least read the --help, a short section in the help about how names get managed, could avoid the confusion, and keep the build clean.
My proposal for help addition is:

Names:
    Declared names are C identifiers; HAL exports them with underscores
    replaced by dashes.  'pin in float my_input' is reached as
    'component.N.my-input'.  After loadrt, 'halcmd show pin component'
    lists the exported names.

[BsAtHome]

Isn't this already described in https://linuxcnc.org/docs/devel/html/en/hal/comp.html ?

[grandixximo]

Correct, but the OP, before edits (the whole reason this PR started), was because the user and his AI missed that, the original proposal was a noisy my_pin =>my-pin to stdout silenced with a flag, basically an in your face "WARNING: names have changed", displayed even for those who know this, and those who reads the docs, arguably useful for newcomers, but an eyesore for veterans.
I think within the original motivation there was an acceptable argument: this behavior is only documented in the comp.adoc

An addition in the --help will improve visibility, and will weaken the "is not well documented" argument, after the addition in --help there are less excuses for missing it, AI or human...

[BsAtHome]

The --help is there to remind you of command line switches. Not to tell you how to write content. That belongs to the man pages and other documentation. The man-page is terse and should link properly to the docs.

And, as you correctly said, no new is good news and errors/warnings are supposed to be one-liner messages with the correct information (in the correct format for IDEs to use).

_{Relying on abnormal intelligence to do the right thing is like asking an amoeba to write Shakespeare. The letters are there but the meaning is lost. As they say, gigo.}

[grandixximo]

The man page argument has a hole for exactly the audience halcompile serves: component developers. They overwhelmingly work from a RIP build (git clone, make, rip-environment), and RIP installs nothing to MANPATH. For them man halcompile returns "No manual entry" unless they also built the docs tree locally. The deb path (linuxcnc-uspace-dev) ships the man page, but that package is for people compiling components against an installed system, not the people writing them.

--help is the only documentation guaranteed to be present in every install flavor, at the exact moment someone unfamiliar with the tool looks for orientation.

There is also in-tree precedent for non-switch guidance in this very usage() text: "Do not use [sudo] for RIP installation" is behavioral advice, not a switch reminder.

Not proposing a tutorial, just 4 lines stating the one non-obvious semantic (C identifier => dashed HAL name) plus where to see the result (halcmd show pin). The full HALNAME rules stay in comp.adoc and the man page; the help text would end by pointing there. Zero build noise, zero runtime cost, and it covers the RIP user the man page never reaches.