Repository navigation
[BUG] Cache fingerprinting ignores compiler_directives #7532
Description
Describe the bug
The context is using Cython+coverage.py. To reproduce the bug:
- Build the package without tracing compiler directives/macros
- Build with
cythonize.compiler_directiveswithlinetrace=True+Extensions.define_macroswith tracing macros - The cache outputs a code not taking into account
linetrace, but the macros are defined and passed on to the C/C++ compiler. - No trace is generated at runtime and the Cython code is not part of the coverage report
I think the reason is because of the wrong assumption (compiler_directives does not influence code generation) that is written in a comment in Compiler/Options.py:get_fingerprint:
The fingerprinting function returns a string that will be fed to hash.update in Build/Cache.py:transitive_fingerprint
def get_fingerprint(self):
data = {}
for key, value in self.__dict__.items():
if key in SOMEVALUES:
... # many elif
elif key in ['compiler_directives']:
# directives passed on to the C compiler do not influence the generated code
continue
... # many other elif
str_data = convert_to_string(data)
return dataBut that is wrong, as Cython with linetrace=True generates instrumentation code (such as in Compiler/Code.py:write_trace_line()).
Code to reproduce the behaviour:
No response
Expected behaviour
I would expect Cython cache fingerprinting to take into account compiler_directives (or at least partially compiler_directive.linetrace).
OS
Linux (official docker image python:3.13-slim)
Python version
3.13.12
Cython version
3.2.4
Additional context
No response
Activity
[-][BUG] Caching fingerprint doesn't take into account `compiler_directives`[/-][+][BUG] Caching fingerprint ignore `compiler_directives`[/+][-][BUG] Caching fingerprint ignore `compiler_directives`[/-][+][BUG] Caching fingerprint ignores `compiler_directives`[/+][-][BUG] Caching fingerprint ignores `compiler_directives`[/-][+][BUG] Cache fingerprinting ignores `compiler_directives`[/+]scoder commentedon Feb 17, 2026
Thanks for the report. Yes, that looks like an incorrect assumption in the code. The
compiler_directivesinstruct Cython itself to apply a certain behaviour, usually leading to different C code being generated. What might have been meant is the C macros etc., but the code is wrong as it stands.We might want to be a bit selective about directives that do not impact the generated result but should otherwise include the directives state in the fingerprint.
scoder commentedon Feb 18, 2026
We'd be happy to receive a PR, BTW. :)
v01dXYZ commentedon Feb 18, 2026
Do you want me to first put back
compiler_directivesin thedatadictionary? A finer grain approach would need to list all thecompiler_directivesoption and to document exactly when they do not influence code generation.scoder commentedon Feb 18, 2026
I think we can start with the directives dict taken into account as a whole, then exclude what we can. Some exclusions are obvious, like the warning and test directives.
The code above the
_directive_defaultsalready has a few functions that copy the current directives with exclusions. I'd add a new one there.Fix cache ignoring `compiler_directives` when fingerprinting compiler…
build: add opt-in Cython generated-source cache
build: add opt-in Cython generated-source cache
build: add opt-in Cython generated-source cache (#2933)
Fix cache ignoring `compiler_directives` when fingerprinting compiler…
Fix cache ignoring `compiler_directives` when fingerprinting compiler…