view tests/test-basic.t @ 25174:86298718b01c

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.

Create a repository:

  $ hg config
  defaults.backout=-d "0 0"
  defaults.commit=-d "0 0"
  defaults.shelve=--date "0 0"
  defaults.tag=-d "0 0"
  devel.all=true
  largefiles.usercache=$TESTTMP/.cache/largefiles (glob)
  ui.slash=True
  ui.interactive=False
  ui.mergemarkers=detailed
  ui.promptecho=True
  $ hg init t
  $ cd t

Make a changeset:

  $ echo a > a
  $ hg add a
  $ hg commit -m test

This command is ancient:

  $ hg history
  changeset:   0:acb14030fe0a
  tag:         tip
  user:        test
  date:        Thu Jan 01 00:00:00 1970 +0000
  summary:     test
  

Verify that updating to revision 0 via commands.update() works properly

  $ cat <<EOF > update_to_rev0.py
  > from mercurial import ui, hg, commands
  > myui = ui.ui()
  > repo = hg.repository(myui, path='.')
  > commands.update(myui, repo, rev=0)
  > EOF
  $ hg up null
  0 files updated, 0 files merged, 1 files removed, 0 files unresolved
  $ python ./update_to_rev0.py
  1 files updated, 0 files merged, 0 files removed, 0 files unresolved
  $ hg identify -n
  0


Poke around at hashes:

  $ hg manifest --debug
  b789fdd96dc2f3bd229c1dd8eedf0fc60e2b68e3 644   a

  $ hg cat a
  a

Verify should succeed:

  $ hg verify
  checking changesets
  checking manifests
  crosschecking files in changesets and manifests
  checking files
  1 files, 1 changesets, 1 total revisions

At the end...

  $ cd ..