Skip to content

Conversation

@perazz
Copy link
Member

@perazz perazz commented Jan 21, 2026

Summary

  • macro_in_list now handles NAME=VALUE format macros (e.g., STDLIB_BITSET=1)
  • parse_if_condition now handles defined MACRO without parentheses (in addition to defined(MACRO))
  • Added macro_is_truthy for proper #if MACRO evaluation per CPP semantics
  • Add tests

Fix the example_packages/metapackage_stdlib build which uses stdlib's macros.inc with #if !defined STDLIB_BITSET syntax.

cc: @jvdp1

- macro_in_list now handles NAME=VALUE format macros
- parse_if_condition now handles 'defined MACRO' without parentheses
- Added macro_is_truthy for proper #if MACRO evaluation per CPP semantics
Tests that:
- Undefined macros evaluate to false
- MACRO=0 evaluates to false
- MACRO=1 evaluates to true
- MACRO=non-zero evaluates to true
- Empty macro (defined without value) evaluates to true
Tests macros defined inside source via #define with all formats:
- #if MACRO (truthy evaluation)
- #ifdef MACRO (existence check)
- #if defined(MACRO) (with parentheses)
- #if defined MACRO (without parentheses)
- #if !defined MACRO (negated)
- #if MACRO == value (equality)
- #if MACRO != value (inequality)
@jvdp1
Copy link
Member

jvdp1 commented Jan 21, 2026

Thank you @perazz . I confirmed that this PR fixed the issue with stdlib-fpm.

What was the issue?

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

This PR enhances the C preprocessor (CPP) macro parsing capabilities to fix compatibility with stdlib's macros.inc. The changes implement proper support for NAME=VALUE macro format, defined MACRO syntax without parentheses, and improved truthiness evaluation following CPP semantics.

Changes:

  • Enhanced macro_in_list to handle NAME=VALUE format macros
  • Extended parse_if_condition to support defined MACRO syntax without parentheses
  • Added macro_is_truthy function for proper #if MACRO evaluation per CPP semantics

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File Description
src/fpm_source_parsing.f90 Updated macro detection logic to be case-sensitive and handle value assignments; added support for defined MACRO without parentheses; implemented macro_is_truthy for proper CPP truthiness evaluation
test/fpm_test/test_source_parsing.f90 Added comprehensive tests for macro case sensitivity, truthiness evaluation, and various CPP conditional formats

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

@perazz
Copy link
Member Author

perazz commented Jan 21, 2026

The new macros defined with values were checked as booleans #if MACRO while fpm would only check #if MACRO == 1. Now both forms should be properly captured.

Per CPP standard, macro names and values should be compared case-sensitively.
This makes get_macro_value and parse_macro_comparison consistent with macro_in_list.
Per standard CPP, #define MACRO followed by #if MACRO evaluates to
#if (empty) which is equivalent to #if 0 (false).
@perazz perazz force-pushed the fix-cpp-defined-macro-parsing branch from 5fd3004 to 98d0e75 Compare January 21, 2026 21:26
Add locally_defined parameter to macro_is_truthy:
- locally_defined=.false. (fpm.toml/command line): empty = true (like -DMACRO)
- locally_defined=.true. (#define in source): empty = false (CPP error)

This matches exact CPP behavior:
- gcc -DMACRO treats it as -DMACRO=1 (truthy)
- #define MACRO in source with #if MACRO is a CPP error (empty expression)
@perazz perazz force-pushed the fix-cpp-defined-macro-parsing branch from 98d0e75 to 1572a70 Compare January 21, 2026 21:33
@perazz perazz merged commit f974480 into fortran-lang:main Jan 22, 2026
32 checks passed
@rouson
Copy link
Contributor

rouson commented Jan 23, 2026

@perazz any thoughts of minting a release soon? I created a draft release three days ago, but it's already out of date with a dozen new commits hitting the main branch since just within the past 2 days. Also, due to prior commitments, it's likely to be several weeks before I can make time to complete the release workflow. As soon as 0.13.0 is available, I plan to update several projects' documentation to cite 0.13.0 as the preferred version.

@perazz
Copy link
Member Author

perazz commented Jan 23, 2026

Thank you @rouson, sorry I did not receive a notification for your release draft and had overlooked it (please ensure you ping me when you need me). Extremely busy time, but I should be able to complete this release this weekend.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants