Entity as enum about clang-rs HOT 8 CLOSED

Yeah, it kinda sucks. It's still 100x easier to use than the raw bindings.

The libclang API is just really awkward, even as C APIs go.

from clang-rs.

d7507ed

from clang-rs.

Interesting, I hadn't thought about that.

Another idea would be to leave Entity as a struct but add fields that are specific to only a few EntityKinds to the EntityKind variant.

E.g., Entity::get_file would be removed (because it is only used for inclusion directives) and the EntityKind::InclusionDirective variant would become EntityKind::InclusionDirective(File<'tu>).

I'll have to think about it.

from clang-rs.

I've thought about it, and I'm not sure it's worth the implementation difficulty. There would still be many fields common to most entity kinds.

if let Entity::InclusionDirective(file) = entity {
    let name = entity.get_name().unwrap();
}

doesn't seem much better than

if entity.get_kind() == EntityKind::InclusionDirective {
    let name = entity.get_name().unwrap();
    let file = entity.get_file().unwrap();
}

to me.

There's less unwrap with the pattern matching, but it wouldn't eliminate it completely. Some entities would still have an optional name and some would still have an optional source range.

from clang-rs.

However, something like

if let EntityKind::InclusionDirective(file) = entity.get_kind() {
    let name = entity.get_name().unwrap();
}

might work. I'll start looking into it.

from clang-rs.

Well I tried, but it doesn't seem practical to map libclang's API into anything other than what it is now.

from clang-rs.

The you crate is not really rust idiomatic ;)

from clang-rs.

This crate will not be used a lot (only crates which manipulates c code), so it's not a big issue.

from clang-rs.