universal-ctags
javascript: Got "ctags: Warning: ignoring null tag"
[yamato@x201]~/var/ctags-github% cat /tmp/foo.js
if (true) {
this[0] = function() {};
}
[yamato@x201]~/var/ctags-github% ./ctags -o - /tmp/foo.js
ctags: Warning: ignoring null tag in /tmp/foo.js(line: 2)
[yamato@x201]~/var/ctags-github% js /tmp/foo.js
[yamato@x201]~/var/ctags-github%
Is there any update on this?
Or am I doing something wrong? The code I'm trying to tag is Javascript/React :)
Apparently it is related to Object destructuring like:
const { name, email } = user;
I have not inspected the warning well. However, the input you gave looks valid as I tested the input on node command I would like you to open a new issue for the input. If you are good at JavaScript, I would like to know the specification as reference. See https://github.com/universal-ctags/ctags/issues/1949#issuecomment-457829914 how I struggled.
const { name, email } = user;
name and email should be tagged well.
[yamato@slave]~% node
> var user = {name: 'a', email: 'b'}
var user = {name: 'a', email: 'b'}
undefined
> const { name, email } = user;
const { name, email } = user;
undefined
> name
name
'a'
If you are good at JavaScript, I would like to know the specification as reference.
Not sure if I got your question but the specification for the Object Destructuring is on the ECMAScript specification: https://www.ecma-international.org/ecma-262/6.0/#sec-destructuring-assignment
:)
how did you remove the warning?
I didn't remove the warning.
well, I've got the same issue, {A, B} = some_obj can be parsed correctly by ctags.
Looks like no one is going to fix this issue
For the destructural binding, I tried once.
[jet@living]/tmp% cd /tmp
cd /tmp
[jet@living]/tmp% git clone https://github.com/masatake/ctags.git
git clone https://github.com/masatake/ctags.git
Cloning into 'ctags'...
...
[jet@living]/tmp% cd ctags
cd ctags
[jet@living]/tmp/ctags% git checkout origin/js-destructual-binding
git checkout origin/js-destructual-binding
Note: switching to 'origin/js-destructual-binding'.
...
HEAD is now at 4eeac5b9 JavaScript: support more forms of destructuring assignments
[jet@living]/tmp/ctags% bash ./autogen.sh
bash ./autogen.sh
+ type autoreconf
...
optlib2c: translating optlib/inko.ctags to optlib/inko.c
+ ./misc/optlib2c optlib/inko.ctags
+ exit 0
[jet@living]/tmp/ctags% ./configure
./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
...
config.status: creating config.h
config.status: executing depfiles commands
[jet@living]/tmp/ctags% make -j 9
make -j 9
REPOINFO main/repoinfo.h
make all-recursive
make[1]: Entering directory '/tmp/ctags'
make[2]: Entering directory '/tmp/ctags'
...
AR libctags.a
CCLD ctags
CCLD mini-geany
make[2]: Leaving directory '/tmp/ctags'
make[1]: Leaving directory '/tmp/ctags'
[jet@living]/tmp/ctags% cat /tmp/bar.js
cat /tmp/bar.js
const { name, email } = user;
[jet@living]/tmp/ctags% ./ctags -o - /tmp/bar.js
./ctags -o - /tmp/bar.js
email /tmp/bar.js /^const { name, email } = user;$/;" C
name /tmp/bar.js /^const { name, email } = user;$/;" C
The branch introduces so many changes. So merging it to the master branch we use daily needs more consideration.
this[0] = function() {};
In this case, ctags says nothing.
{
this[0] = function() {};
}
In this case, I got a warning. This will be an important hint fix for the original input.
Looks like no one is going to fix this issue
For the destructural binding, I tried once.
[jet@living]/tmp% cd /tmp cd /tmp [jet@living]/tmp% git clone https://github.com/masatake/ctags.git git clone https://github.com/masatake/ctags.git Cloning into 'ctags'... ... [jet@living]/tmp% cd ctags cd ctags [jet@living]/tmp/ctags% git checkout origin/js-destructual-binding git checkout origin/js-destructual-binding Note: switching to 'origin/js-destructual-binding'. ... HEAD is now at 4eeac5b9 JavaScript: support more forms of destructuring assignments [jet@living]/tmp/ctags% bash ./autogen.sh bash ./autogen.sh + type autoreconf ... optlib2c: translating optlib/inko.ctags to optlib/inko.c + ./misc/optlib2c optlib/inko.ctags + exit 0 [jet@living]/tmp/ctags% ./configure ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes ... config.status: creating config.h config.status: executing depfiles commands [jet@living]/tmp/ctags% make -j 9 make -j 9 REPOINFO main/repoinfo.h make all-recursive make[1]: Entering directory '/tmp/ctags' make[2]: Entering directory '/tmp/ctags' ... AR libctags.a CCLD ctags CCLD mini-geany make[2]: Leaving directory '/tmp/ctags' make[1]: Leaving directory '/tmp/ctags' [jet@living]/tmp/ctags% cat /tmp/bar.js cat /tmp/bar.js const { name, email } = user; [jet@living]/tmp/ctags% ./ctags -o - /tmp/bar.js ./ctags -o - /tmp/bar.js email /tmp/bar.js /^const { name, email } = user;$/;" C name /tmp/bar.js /^const { name, email } = user;$/;" CThe branch introduces so many changes. So merging it to the master branch we use daily needs more consideration.
I've tried it, a very good solution, thanks. Did you made these branches, so many patches.
Hi
Although this is not contributing to the issue in ctags itself, I created a ctags shell function that ignores this specific warning for JavaScript files: https://gist.github.com/dietrichm/9e518549fd609173182ce36ac4726df2
Just in case you frequently run ctags on the command line and want to hide the warnings until the issue is fixed.
Dietrich
I also get this warning with array destructuring :
const [lang, setLang] = useState("en")
FYI: If you pass the --quiet=yes command-line option, this warning is not shown anymore. While not being a perfect solution, it at least silences the clutter.
FYI: If you pass the
--quiet=yescommand-line option, this warning is not shown anymore. While not being a perfect solution, it at least silences the clutter.
That does not shut it up on my side, at all :shrug:
I'll have to go with @dietrichm alternative for the time being as I'm heavily using deconstruction which ctags really spammy.
Could you try #3435?
I'm moving to the PR. Let me know if you want to keep it here.
For the original issue, the fix is in #3762. Closing, since #3435 is working on the much larger destructuring issue.
