The enum value for CXCursor_TranslationUnit is 350.

[cfis]

See https://githhub.com/llvm/llvm-project/blob/main/clang/include/clang-c/Index.h#L2143

[ioquatix]

Thanks.

[ioquatix]

I tested this locally on macOS, which as we all know uses a odd release of clang, and it failed, I think it's still expecting the value 300.

Is this just some oddity of Clang on macOS? Or is this some oddity of Clang in general?

In other words, do we need to special case this const value on different clang versions/platforms/releases?

[ioquatix]

Just FYI:

  23) FFI::Clang::TranslationUnit#cursor returns translation unit cursor if no arguments are specified
      Failure/Error: expect(cursor.kind).to eq(:cursor_translation_unit)
      
        expected: :cursor_translation_unit
             got: 300
      
        (compared using ==)

I'd like to at least figure out what to do before making a new release. Of course, it seems fine on the official releases of clang..........

If you have time, do you mind investigating?

[cfis]

Ok - that value changed June 16, 2022 in this commit:

sx-aurora-dev/llvm-project@bb83f8e

No idea why they would change an existing enum value.

Anyway, that probably means it is in Clang 15 (released Sept 6, 2022) and higher.

One approach is what you said - the latest version of the gem should work with newer versions of Clang, and if you have an older version of Clang than use an older version of the gem.

Alternatively, it would be easy to add a Clang version check in the code that defines the enum based on the Clang version. Similar to what I do in the Proj4rb gem. See:

https://github.com/cfis/proj4rb/blob/master/lib/api/api_6_0.rb#L77

I would take the second approach. Thoughts?

[ioquatix]

I suppose macOS is a fairly important target, so the 2nd approach makes more sense to me.

Yeah, it's surprising they'd change an enum value like that.