Hi,
After a suggestion by Chris, I've added a page to track C++ support in Clang:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080630/006333.html
Please feel free to add something I missed, change wording and/or change the whole design of the page.
Later I'll link to this page by the front page ("Current Status") and get_involved.html ("Open Projects"/"Continue work on C++ support").
-Argiris
Argiris Kirtzidis wrote:
Hi,
After a suggestion by Chris, I've added a page to track C++ support in Clang:
Oh yeah, check it out by browsing here: Clang - C++ Programming Language Status
-Argiris
Please feel free to add something I missed, change wording
and/or change the whole design of the page.
Design: maybe make the table borderless, but at least not with
the ugly double borders 
Maybe make "Parser & Sema" and "Codegen" two columns. Also I'm
not sure if many people that read the page knows what "Sema"
means.
Maybe drop the "C++ " at each line in the "Feature" column. It's
clear that this page applies to C++
Maybe use valign="top"
Right now the page gives the impression that "Parsing and Sema"
is basically done and just codegen is missing. However, lot's of
C++ features are missing. Maybe adding them would give a better
impression of the real state. Maybe something like:
Templates
Overloading
Operator overloading
Maybe we can use something like
and re-use their TOC for this purpose. The paper from above URL
just showed up after googling for "c++ standard", maybe there is
something better or even ratified available on the net.
Holger Schurig wrote:
Design: maybe make the table borderless, but at least not with the ugly double borders
I'm not much of a html designer, the table has border="1", what should I put for 'single' borders ?
Maybe make "Parser & Sema" and "Codegen" two columns. Also I'm not sure if many people that read the page knows what "Sema" means.
How about 1 column for "Parser & Semantic analysis" and another for "Code generation"
Maybe drop the "C++ " at each line in the "Feature" column. It's clear that this page applies to C++
Ok.
Maybe use valign="top"
I tried that but didn't make a difference wherever I put it (table,tr,td) (at least on firefox that is).
Right now the page gives the impression that "Parsing and Sema" is basically done and just codegen is missing. However, lot's of C++ features are missing. Maybe adding them would give a better impression of the real state. Maybe something like:
Templates
Overloading
Operator overloadingMaybe we can use something like http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf and re-use their TOC for this purpose. The paper from above URL just showed up after googling for "c++ standard", maybe there is something better or even ratified available on the net.
I'm not sure if providing a looong list of missing C++ features is going to be much more helpful.
How about we just make it clear that this page lists only C++ features that Clang has partial/full support for. When clang reaches a point where most of C++ is at least partially supported, we can add the missing stuff too to complete the picture.
-Argiris
> Maybe use valign="top"
I tried that but didn't make a difference wherever I put it
(table,tr,td) (at least on firefox that is).
Couldn't you do that via CSS then ?
I'm not sure if providing a looong list of missing C++
features is going to be much more helpful.
How about we just make it clear that this page lists only C++
features that Clang has partial/full support for. When clang
reaches a point where most of C++ is at least partially
supported, we can add the missing stuff too to complete the
picture.
Okay, then the page could state "Currently, we only support the
following features whole or partially" (but let a native english
speaker correct this sentence first
BTW, I always like the GNU classpath display of
feature-completeness, e.g. look at
http://builder.classpath.org/japi/jdk15-classpath.html
However, that would need a) a good listing of features, b) lot's
of little test programs for those features, c) either a database
and a CGI or a little tool that does the tests and generates a
static html page.
Holger Schurig wrote:
Couldn't you do that via CSS then ?
CSS works, thanks!
I'm not sure if providing a looong list of missing C++
features is going to be much more helpful.
How about we just make it clear that this page lists only C++
features that Clang has partial/full support for. When clang
reaches a point where most of C++ is at least partially
supported, we can add the missing stuff too to complete the
picture.
Okay, then the page could state "Currently, we only support the following features whole or partially" (but let a native english speaker correct this sentence first
I've added a note about this.
BTW, I always like the GNU classpath display of feature-completeness, e.g. look at http://builder.classpath.org/japi/jdk15-classpath.html
However, that would need a) a good listing of features, b) lot's of little test programs for those features, c) either a database and a CGI or a little tool that does the tests and generates a static html page.
That would be very cool!
-Argiris
Is a page like this really useful at this point? There's really so
much missing that clang is basically useless for C++ at the moment.
Some examples: C++-compatible conversions, constant-folding,
inheritance, exceptions, overloading, constructors, copy-conversion,
friends, custom operators, function-style type conversions, labels for
declarations.
-Eli
Hi Argiris,
I think this is a good start for a page like this. Besides incorporating some of the feedback from the other responders, you might want to consider not using the terms "Sema", "CodeGen", "Parse", etc. These are libraries used to implement features, and are not the features themselves. Using these terms makes the page only useful to people who understand Clang's internals (i.e., Clang developers), and this page really should be targeted to a much broader audience (i.e., anybody who cares about C++ support in Clang).
I would use the following terms instead:
Parse -> "parsing"
Sema -> "type checking"
CodeGen -> "code generation (compilation)"
For those who know the internals of Clang, they will be able to do the reverse mapping just fine.
Ted
Hi,
After a suggestion by Chris, I’ve added a page to track C++ support in
Clang:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080630/006333.htmlPlease feel free to add something I missed, change wording and/or change
the whole design of the page.Later I’ll link to this page by the front page (“Current Status”) and
get_involved.html (“Open Projects”/“Continue work on C++ support”).Is a page like this really useful at this point? There’s really so
much missing that clang is basically useless for C++ at the moment.
Some examples: C+±compatible conversions, constant-folding,
inheritance, exceptions, overloading, constructors, copy-conversion,
friends, custom operators, function-style type conversions, labels for
declarations.
I find it useful, as I’m extremely interested in the progress being made. Also, there are many applications which can leverage Clang without codegen for these constructs. Pretty printing HTML, analysis, AST representations, etc. It’s just easier to check this type of page than to read all the commit and dev emails.
-Chandler
I strongly agree. Also, as I pointed out in my other email, it makes the C++ progress more transparent to non-Clang developers. Without a page like this non-Clang developers can only guess about the progress of C++ support (and most will assume that it doesn't exist at all).
Actively publishing the development progress for key Clang features also has the added benefit that it will help attract more attention to the project. Such attention can bring both new users and contributors. Further, if the information is presented in a way that non-Clang developers can understand, it also means that articles written about LLVM/Clang on tech-related websites and blogs might be marginally more accurate.
Ted Kremenek wrote:
Hi,
After a suggestion by Chris, I've added a page to track C++ support in
Clang:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080630/006333.htmlPlease feel free to add something I missed, change wording and/or change
the whole design of the page.Later I'll link to this page by the front page ("Current Status") and
get_involved.html ("Open Projects"/"Continue work on C++ support").Hi Argiris,
I think this is a good start for a page like this. Besides incorporating some of the feedback from the other responders, you might want to consider not using the terms "Sema", "CodeGen", "Parse", etc. These are libraries used to implement features, and are not the features themselves. Using these terms makes the page only useful to people who understand Clang's internals (i.e., Clang developers), and this page really should be targeted to a much broader audience (i.e., anybody who cares about C++ support in Clang).
I would use the following terms instead:
Parse -> "parsing"
Sema -> "type checking"
CodeGen -> "code generation (compilation)"For those who know the internals of Clang, they will be able to do the reverse mapping just fine.
Would it be better to do Sema->"AST building" ?
-Argiris
Your comment is wrong for reinterpret_cast. You don't always cast from a pointer to a pointer. reinterpret_cast allows you to cast from a pointer to non-pointer, as long as the type cast to can hold the size of the pointer's value without loss of precision. So clang fails to emit an error in this situation:
$ cat t.cpp
#include <stdint.h>
void foo(int *f) {
uintptr_t cp = reinterpret_cast<uintptr_t>(f);
char c = reinterpret_cast<char>(f);
}
$ clang -fsyntax-only t.cpp
$ g++ -c t.cpp
t.cpp: In function 'void foo(int*)':
t.cpp:5: error: cast from 'int*' to 'char' loses precision
$
Please reference the patch I sent out many weeks ago for review. It didn't pass muster, but at least caught situations like this.
-bw
More situations it doesn't emit errors for:
typedef double *dptr;
typedef const double *cdptr;
void reinterpret_cast_check() {
short s;
double *d;
float *f;
const double * const ccd; // FIXME: Should error about uninitialized const.
const double *cd;
int const * volatile * vci;
double * const * volatile * *vcd;
dptr t_d;
cdptr t_cd;
// No errors:
t_d = reinterpret_cast<dptr>(d);
f = reinterpret_cast<float*>(d);
cd = reinterpret_cast<const double *>(ccd);
// Expected errors:
f = reinterpret_cast<float*>(cd); // expected-error {{reinterpret_cast cannot cast \
away const}}
s = reinterpret_cast<short>(f); // expected-error {{loss of precision}}
vcd = reinterpret_cast<double*const*volatile**>(vci); // expected-error {{reinterpr\
et_cast cannot cast away const}}
t_d = reinterpret_cast<dptr>(t_cd); // expected-error {{reinterpret_cast cannot cas\
t away const}}
}
Enjoy!
-bw
That assumes that everyone knows what an AST is, and for some people "parsing" == "AST building." The meta point here is "non-Clang developers" includes "non-compiler people" who still want to know that Clang is something worth caring about.
I think that using contractions like this is ok. I added a paragraph to the top explaining what they mean and made the table use a nicer looking border.
-Chris
I'm not completely sure what this comment is in reply to, but I don't
see the relevance to this discussion. Are you arguing that we don't
have full support for reinterpret_cast, and therefore shouldn't claim
that?
In any case, would you mind making sure this is filed in Bugzilla so
we don't lose track of it?
-Eli
Your comment is wrong for reinterpret_cast. You don't always cast
from a pointer to a pointer. reinterpret_cast allows you to cast from
a pointer to non-pointer, as long as the type cast to can hold the
size of the pointer's value without loss of precision. So clang fails
to emit an error in this situation:I'm not completely sure what this comment is in reply to, but I don't
see the relevance to this discussion. Are you arguing that we don't
have full support for reinterpret_cast, and therefore shouldn't claim
that?
Yup! It's on Argiris' web page and should be updated with the correct
information. So should the comment in the source code.
In any case, would you mind making sure this is filed in Bugzilla so
we don't lose track of it?
"Do correct semantic analysis for reinterpret_cast"? What about all of
the 10^100 other features that don't work/aren't done for C++?
-bw
Ah, nevermind; I didn't realize that the reinterpret_cast
implementation doesn't do any typechecking at all. It's definitely
misleading to list "reinterpret_cast" next to "Full support", and
claim we have full Sema support for "Named Casts".
-Eli
Hi Bill,
Bill Wendling wrote:
Thanks! Are you (or someone else) going to work on full sema
support for reinterpret_cast (and friends) or should I try to port my
previous patch over to the new way of doing stuff? If others are going
to do it, I suggest cannibalizing my patch.
-bw