cpython/Tools/c-analyzer
Victor Stinner a60ddd31be
gh-98401: Invalid escape sequences emits SyntaxWarning (#99011)
A backslash-character pair that is not a valid escape sequence now
generates a SyntaxWarning, instead of DeprecationWarning.  For
example, re.compile("\d+\.\d+") now emits a SyntaxWarning ("\d" is an
invalid escape sequence), use raw strings for regular expression:
re.compile(r"\d+\.\d+"). In a future Python version, SyntaxError will
eventually be raised, instead of SyntaxWarning.

Octal escapes with value larger than 0o377 (ex: "\477"), deprecated
in Python 3.11, now produce a SyntaxWarning, instead of
DeprecationWarning. In a future Python version they will be
eventually a SyntaxError.

codecs.escape_decode() and codecs.unicode_escape_decode() are left
unchanged: they still emit DeprecationWarning.

* The parser only emits SyntaxWarning for Python 3.12 (feature
  version), and still emits DeprecationWarning on older Python
  versions.
* Fix SyntaxWarning by using raw strings in Tools/c-analyzer/ and
  wasm_build.py.
2022-11-03 17:53:25 +01:00
..
c_analyzer Fix typos in the Tools directory (GH-28769) 2021-10-06 10:55:16 -07:00
c_common gh-90110: Fix the c-analyzer Tool (gh-96731) 2022-09-12 11:09:31 -06:00
c_parser gh-98401: Invalid escape sequences emits SyntaxWarning (#99011) 2022-11-03 17:53:25 +01:00
cpython GH-98686: Quicken everything (GH-98687) 2022-11-02 10:42:57 -07:00
README bpo-36876: Fix the C analyzer tool. (GH-22841) 2020-10-22 18:42:51 -06:00
TODO gh-78607: Replace __ltrace__ with __lltrace__ (GH-91619) 2022-04-16 18:57:00 -04:00
c-analyzer.py bpo-36876: Fix the C analyzer tool. (GH-22841) 2020-10-22 18:42:51 -06:00
check-c-globals.py gh-90110: Get the C Analyzer Tool Working Again (gh-95545) 2022-08-01 17:13:23 -06:00
must-resolve.sh bpo-36876: [c-analyzer tool] Additional CLI updates for "capi" command. (gh-23929) 2020-12-25 15:57:30 -07:00
table-file.py bpo-36876: Minor cleanup to c-analyzer "ignored" data.' (gh-31239) 2022-02-09 17:10:53 -07:00

README

#######################################
# C Globals and CPython Runtime State.

CPython's C code makes extensive use of global variables.  Each global
falls into one of several categories:

* (effectively) constants (incl. static types)
* globals used exclusively in main or in the REPL
* freelists, caches, and counters
* process-global state
* module state
* Python runtime state

The ignored-globals.txt file is organized similarly.  Of the different
categories, the last two are problematic and generally should not exist
in the codebase.

Globals that hold module state (i.e. in Modules/*.c) cause problems
when multiple interpreters are in use.  For more info, see PEP 3121,
which addresses the situation for extension modules in general.

Globals in the last category should be avoided as well.  The problem
isn't with the Python runtime having state.  Rather, the problem is with
that state being spread throughout the codebase in dozens of individual
globals.  Unlike the other globals, the runtime state represents a set
of values that are constantly shifting in a complex way.  When they are
spread out it's harder to get a clear picture of what the runtime
involves.  Furthermore, when they are spread out it complicates efforts
that change the runtime.

Consequently, the globals for Python's runtime state have been
consolidated under a single top-level _PyRuntime global. No new globals
should be added for runtime state.  Instead, they should be added to
_PyRuntimeState or one of its sub-structs.  The check-c-globals script
should be run to ensure that no new globals have been added:

  python3 Tools/c-analyzer/check-c-globals.py

You can also use the more generic tool:

  python3 Tools/c-analyzer/c-analyzer.py

If it reports any globals then they should be resolved.  If the globals
are runtime state then they should be folded into _PyRuntimeState.
Otherwise they should be added to ignored-globals.txt.