bug#19741: 25.0.50; find-tag completion uses an outdated cache of the tags table

[Eli Zaretskii <eliz@gnu.org>]

> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Sun, 01 Feb 2015 21:59:10 +0200
> 
> 1. M-x find-file lisp/progmodes/etags.el. Being in that buffer, and not
> in *scratch*, is somehow important.
> 
> 2. M-x visit-tags-table ../../lisp/TAGS.
> 
> 3. M-x find-tag, press TAB, see the table loaded.
> 
> 4. M-x visit-tags-table, ../../src/TAGS, press `y' (important!).
> 
> 5. M-x find-tag, type `display_li', press TAB, see [No matches]!
> 
> The main scenario ends here.
> 
> 6. Finish typing `display_line', press RET, see the navigation succeed
> anyway (with a jump to src/xdisp.c:20013).
> 
> 7. Press `M-,' to get back to etags.el, repeat 5., see the same result.
> 
> 8. M-x find-file ../../src/search.c, repeat 5., see a different result.

I think this happens because visiting the second TAGS table doesn't
invalidate or recalculate tags-completion-table, which was generated
when you pressed TAB at the first find-tag prompt.  Look at the
function tags-completion-table, it does this:

  (defun tags-completion-table ()
    "Build `tags-completion-table' on demand.
  The tags included in the completion table are those in the current
  tags table and its (recursively) included tags tables."
    (or tags-completion-table
	;; No cached value for this buffer.

IOW, it reuses the existing value of tags-completion-table (the
variable).  However, visiting the second TAGS table didn't update the
completion table, so you get "No match".