I want to write an extension type with a method that takes a typed-memory-view as one of its arguments. MWE:
main.pyx
# cython: language_level = 3
cdef class main:
cdef void foo(self, double [:] x):
pass
setup.py
from setuptools import setup
from Cython.Build import cythonize
if __name__ == "__main__":
setup(ext_modules=cythonize("main.pyx"))
When I run the code (the real one) everything seems to work fine, but I get the following compilation warning:
running build_ext
building 'main' extension
clang -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk -I/usr/local/opt/[email protected]/Frameworks/Python.framework/Versions/3.10/include/python3.10 -c main.c -o build/temp.macosx-12-x86_64-cpython-310/main.o
main.c:19220:21: warning: fallthrough annotation in unreachable code [-Wunreachable-code-fallthrough]
CYTHON_FALLTHROUGH;
^
main.c:353:34: note: expanded from macro 'CYTHON_FALLTHROUGH'
#define CYTHON_FALLTHROUGH __attribute__((fallthrough))
^
main.c:19231:21: warning: fallthrough annotation in unreachable code [-Wunreachable-code-fallthrough]
CYTHON_FALLTHROUGH;
^
main.c:353:34: note: expanded from macro 'CYTHON_FALLTHROUGH'
#define CYTHON_FALLTHROUGH __attribute__((fallthrough))
^
2 warnings generated.
clang -bundle -undefined dynamic_lookup -isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX12.sdk build/temp.macosx-12-x86_64-cpython-310/main.o -o build/lib.macosx-12-x86_64-cpython-310/main.cpython-310-darwin.so
ld: warning: -undefined dynamic_lookup may not work with chained fixups
copying build/lib.macosx-12-x86_64-cpython-310/main.cpython-310-darwin.so ->
I don't know what it means, but it only happens when the extension type has a method that takes a typed-memory-view as an argument.
Should I do anything about it?
This is almost certainly a non-issue. Essentially C has a slightly counter-intuitive behaviour for its switch
:
switch (x) {
case 1:
func1();
case 2:
func2();
break;
case 3:
func3();
}
If you call it with x==1
it'll run func1()
and func2()
(but not func3()
because break
tells it to end jump out of the switch. This is calling "falling through". You usually don't want that, and so a lot of compilers will warn you if you don't end a switch case
with break
.
However, sometimes you do want it, and you can use an optional attribute (which is non-standard and compiler dependent) to say "I really do want to fall through". In this case the attribute is __attribute__((fallthrough))
.
In addition, Cython generates a lot of C code that's actually designed to be optimized out - most of the time the compiler will be able to see that only one branch can happen and drop the other branches. This is because it's easier to generate the code and leave the full decision to the C compiler.
In this case the compiler is saying "you've marked a switch-case as 'fallthrough' but you can never even reach it". It isn't a warning that will cause you a problem - if you'd written the code yourself it might suggest that you hadn't thought it through but in a code generator like Cython it's a sensible thing to do re-use generic code.
However - report it as a bug to Cython. As a general rule Cython tries to minimize the number of C warnings (because they worry people), so if there's an easy way to avoid it that would be an improvement.