tests/test-mq-qgoto.t
author FUJIWARA Katsunori <foozy@lares.dti.ne.jp>
Mon, 18 May 2015 02:52:55 +0900
changeset 25174 86298718b01c
parent 18342 de99de39ba28
child 26780 bbf544b5f2e9
permissions -rw-r--r--
import-checker: make imported_modules yield absolute dotted_name_of_path This patch makes `imported_modules()` always yield absolute `dotted_name_of_path()`-ed name by strict detection with `fromlocal()`. This change improves circular detection in some points: - locally defined modules, of which name collides against one of standard library, can be examined correctly For example, circular import related to `commands` is overlooked before this patch. - names not useful for circular detection are ignored Names below are also yielded before this patch: - module names of standard library (= not locally defined one) - non-module names (e.g. `node.nullid` of `from node import nullid`) These redundant names decrease performance of circular detection. For example, with files at 1ef96a3b8b89, average loops per file in `checkmod()` is reduced from 165 to 109. - `__init__` can be handled correctly in `checkmod()` For example, current implementation has problems below: - `from xxx import yyy` doesn't recognize `xxx.__init__` as imported - `xxx.__init__` imported via `import xxx` is treated as `xxx`, and circular detection is aborted, because `key` of such module name is not `xxx` but `xxx.__init__` - it is easy to enhance for `from . import xxx` style or so (in the future) Module name detection in `imported_modules()` can use information in `ast.ImportFrom` fully. It is assumed that all locally defined modules are correctly specified to `import-checker.py` at once. Strictly speaking, when `from foo.bar.baz import module1` imports `foo.bar.baz.module1` module, current `imported_modules()` yields only `foo.bar.baz.__init__`, even though also `foo.__init__` and `foo.bar.__init__` should be yielded to detect circular import exactly. But this limitation is reasonable one for improvement in this patch, because current `__init__` files in Mercurial seems to be implemented carefully.

  $ echo "[extensions]" >> $HGRCPATH
  $ echo "mq=" >> $HGRCPATH

  $ hg init a
  $ cd a
  $ echo a > a
  $ hg ci -Ama
  adding a

  $ hg qnew a.patch
  $ echo a >> a
  $ hg qrefresh

  $ hg qnew b.patch
  $ echo b > b
  $ hg add b
  $ hg qrefresh

  $ hg qnew c.patch
  $ echo c > c
  $ hg add c
  $ hg qrefresh

  $ hg qgoto a.patch
  popping c.patch
  popping b.patch
  now at: a.patch

  $ hg qgoto c.patch
  applying b.patch
  applying c.patch
  now at: c.patch

  $ hg qgoto b.patch
  popping c.patch
  now at: b.patch

Using index:

  $ hg qgoto 0
  popping b.patch
  now at: a.patch

  $ hg qgoto 2
  applying b.patch
  applying c.patch
  now at: c.patch

No warnings when using index ... and update from non-qtip and with pending
changes in unrelated files:

  $ hg qnew bug314159
  $ echo d >> c
  $ hg qrefresh
  $ hg qnew bug141421
  $ echo e >> b
  $ hg qrefresh

  $ hg up -r bug314159
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ echo f >> a
  $ echo f >> b
  $ echo f >> c

  $ hg qgoto 1
  abort: local changes found, refresh first
  [255]
  $ hg qgoto 1 -f
  popping bug141421
  popping bug314159
  popping c.patch
  now at: b.patch
  $ hg st
  M a
  M b
  ? c.orig
  $ hg up -qCr.

  $ hg qgoto 3
  applying c.patch
  applying bug314159
  now at: bug314159

Detect ambiguous non-index:

  $ hg qgoto 14
  patch name "14" is ambiguous:
    bug314159
    bug141421
  abort: patch 14 not in series
  [255]

  $ cd ..