BUG: Handle common blocks with kind specifications from modules
#25186
Conversation
| @@ -64,22 +64,22 @@ | |||
| typedefs['unsigned_short'] = 'typedef unsigned short unsigned_short;' | |||
| typedefs['unsigned_long'] = 'typedef unsigned long unsigned_long;' | |||
| typedefs['signed_char'] = 'typedef signed char signed_char;' | |||
| typedefs['long_long'] = """\ | |||
| typedefs['long_long'] = """ | |||
There was a problem hiding this comment.
Are these removals an integral part of this PR?
There was a problem hiding this comment.
Yup, these should really have proper C tests (someday, #21304). Here what's happening is when they are in use, without the preprocessor directives come on the same line (a syntax error). Consider:
int 32;Now with one of these needed typedefs it becomes something like (before the change):
int 32;#ifdefWhich is wrong, and needs to be (and is after this change):
int 32;
#ifdef|
This is F90, not F77, right? Is there a way to specify F77/F90 in Does this need a release note? |
No, we let the compiler figure it out now. There's internal handling for some of the code paths, but not really exposed to the user. I believe it is based on the file extension, but it is pretty liberal about switching to F90 at any point. In general its fine to let the compiler figure it out, especially since at this point, most F77 code is "corrupted" by some F90 feature or the other.
I'm not sure, it is a very niche use case I would assume, since |
|
Thanks @HaoZeke. As for the release note, a general note about progress with f2py is probably better. |
Closes #19161.
Draft until: