Summary:
This module previously used to handle deciding how a particular module should
be imported if it had multiple versions (e.g., pure Python or native).
However, as of D18819680 it was changed to always import the native C version.
Lets go ahead and remove it entirely now. Using `policy.importmod` simply
makes it harder for type checkers to figure out the actual module that will be
used.
The only functionality that `policy.importmod()` still provided was verifying
that the module contained a "version" field that looked like what was
expected. In practice these version numbers are not bumped often, so this
doesn't really seem to provide much value in checking that we imported the
correct version that we expected to be shipped with this release.
Reviewed By: xavierd
Differential Revision: D19958227
fbshipit-source-id: 05f1d027d0a41cf99c4aa93cb84a51e830305077
Summary:
On Windows, there are *two* 8-bit encodings for each process.
* The ANSI code page is used for all `...A` system calls, and this is what
Mercurial uses internally. It can be overridden using the `--encoding`
command line option.
* The OEM code page is used when outputing to the console. Mercurial has no
concept of this, and instead renders to the console using the ANSI code page,
which results in mojibake like "Θ" instead of "é".
Add the concept of an `outputencoding`. If this differs from `encoding`, we
convert from the local encoding to the output encoding before writing to the
console.
On non-Windows platforms, this defaults to the same encoding as the local encoding,
so this is a no-op unless `--outputencoding` is manually specified.
On Windows, this defaults to the codepage given by `GetOEMCP`, causing output
to be converted to the OEM codepage before being printed.
For ordinary strings, the local encoded version is wrapped by `localstr` if the
encoding does not round-trip cleanly. This means the output encoding works
even if the character is not represented in the local encoding.
Unfortunately, the templater is not localstr-clean, which means strings can get
flattened down to the local encoding and the original code points are lost. In
this case we can only output characters which are in the intersection of the
encoding and the output encoding.
Most US English Windows systems use cp1252 for the ANSI code page and cp437 for
the OEM code page. These both contain many accented characters, so users with
accented characters in their names will now see them correctly rendered.
All of this only applies to Python 2.7. In Python 3, everything is Unicode,
the `--encoding` and `--outputencoding` options do nothing, and it just works.
Reviewed By: quark-zju, ikostia
Differential Revision: D19951381
fbshipit-source-id: d5cb8b5bfe2bc131b2e6c3b892137a48b2139ca9
Summary: There are no-ops. This makes type checkers' life slightly easier.
Reviewed By: farnz
Differential Revision: D19673051
fbshipit-source-id: 363eb8a4e799113b16529825d45645807cafe2fc
Summary:
Like revlog, the changelog layer should use bytes for parsing its raw content.
`str` is still used for users, messages, etc.
Reviewed By: markbt
Differential Revision: D19613695
fbshipit-source-id: 4f6758f9fca0788bc89ad5c14d9103f66d19b7f2
Summary:
See D17098991 for our encoding strategy. tl;dr, paths, argv, messages, terminal
(not pipes or files) stdout are utf-8. Non utf-8 paths are unsupported (as they
will have issues on Windows anyway).
This diff changes the encoding module to prefer unicode on Python 3.
Reviewed By: simpkins
Differential Revision: D19594827
fbshipit-source-id: c5c1319d840709bc752b96bed6ca80d10f49669e
Summary:
Our plan for switching to Python 3 is to update many types to use Unicode
strings when appropriate. In particular, we should just go ahead and use
Unicode for environment variables, since this is the Python 3's default
behavior.
This drops the check-code.py check that warns developers against using
`os.environ` directly, and converts several call sites to use `os.environ`
directly instead of using `encoding.environ`
Reviewed By: markbt
Differential Revision: D19591566
fbshipit-source-id: e4ac44dcd5f19cd0bf65ac904fc85edad95a9aed
Summary:
Somehow, pyre isn't able to inline the value of ispy3 and propagate it properly
and thus complains about lots of code paths. Let's inline it everywhere.
Reviewed By: ikostia
Differential Revision: D18816333
fbshipit-source-id: 80f81cb91bef4c6831952f9469401d87040335e2
Summary:
The Mercurial codebase contains over 500 errors, let's ignore them for now, we
can go back to them later to fix them.
Besides the manual change to .pyre_configuration.local, the changes were
generated with:
pyre --output=json check | pyre-upgrade fixme
Reviewed By: singhsrb
Differential Revision: D18803908
fbshipit-source-id: 724db7bd864c0de47a97ef2092bdee9f2cda531f
Summary:
In preparation for merging fb-mercurial sources to the Eden repository,
move everything from the top-level directory into an `eden/scm`
subdirectory.
