optional warning on member access without this

Hi!

when accessing members, I use this-> since it shows the
member access in terms of the language. other common
ways are e.g. using a prefix like m_.

it would be cool if there is an optional warning if a member
is accessed without this->

-Jochen

It would be easy to implement, although we would get strangled if it wasn't completely opt-in :slight_smile:

  - Doug

If you implement this, you might want to consider implementing it for Objective-C as well :slight_smile: (Objective-C uses ‘self’ instead of ‘this’, but otherwise the usage is similar.)

Hi!

is it possible to get the module out of a backend consumer for linking?

At first I create a backend consumer with no output:

  clang::CreateBackendConsumer(clang::Backend_EmitNothing...

Then I do clang::ParseAST

Is it then possible to get the module for linking?
Or do I have to save as BC and then link from files?

-Jochen

Hi Jochen,

Currently we don't have any API for this. It should be easy to add, though, and definitely makes sense.

  - Daniel

is there a chance that it will be done by one of the experts?
I don't have enough insight yet.

-Jochen

Hi!

when developing with clang/llvm I have quite a mess with
pointers, references, llvm::OwningPtr and get()

My suggestion would be (which won't get accepted due to the huge
code base) to have a llvm::Object that has a reference counter and
then a llvm::Pointer that increments/decrements the ref-count inside
the object.
Then for every class there has to be decided if it derives from Object and
always allocated with new and always passed as Pointer<>
or a struct and never allocated with new.

I use this scheme quite long now and never have problems except ring
references in complex graphs which have to be broken manually.

- Jochen

The major reason we don't use reference counting in clang the clang AST (or llvm IR) is that it is a) expensive, and b) we have (or aim to have) very simple ownership policies that make it unnecessary. For other heavier objects (e.g. ASTContext itself), it might make sense though.

-Chris

The major reason we don't use reference counting in clang the clang AST (or llvm IR) is that it is a) expensive, and b) we have (or aim to have) very simple ownership policies that make it unnecessary. For other heavier objects (e.g. ASTContext itself), it might make sense though.

Yes, I also think it the reference counting should be used only for heavier objects, e.g. Module, Preprocessor,
Linker etc., of which you only have one or just a few.
If you use clang/llvm only as a blackbox library without looking into the internals (like AST) then
refcounted objects would be cool.

-Jochen

Hi!

is there a way to access the native llvm fixed width types in clang?

there is of course stdint.h which maps e.g.int32_t to int if int
has 32 bit. But is there a way to access the native types
like i32? perhaps via __i32 or __int(32) or whatever,
ranging from i1 to i256 :wink:
This also would simplify stdint.h.

But I guess this makes internal problens e.g. in the
name mangling.

-Jochen

Many CPUs support many different integer types, for example x86-64 supports i8, i16, i32, i64, i128.

Your best bet is to use the int_fast*_t typedefs from <stdint.h>

-Chris