Open secure-sw-dev-bot opened 2 years ago
Comment from @abeln:
Better error messages for expanding cycles
Once #638 is merged, we'll raise an error when we detect an expanding cycle in a generic struct.
e.g.
struct F _For_any(T) {
struct F<T> *f1; // allowed
struct F<struct F<T> > *f2; // error: expanding cycle
};
The error as displayed in #638 is very basic: it only mentions that there's a cycle, but doesn't mention which structs (nodes) are involved in it. We'd like a better error that mentions the involved structs and fields.
e.g.
struct G _For_any(U);
struct F _For_any(T) {
struct G<struct F<T> > *g;
};
struct G _For_any(T) {
struct F<t> *f; // error: expanding cycle: G (field f), F(field g)
};
Comment from @abeln:
Improve the efficiency of ASTContext::getTypeAppsWithBase.
/// Return all type applications that have the given generic decl as base.
/// This is currently slow since it iterates over all cached type applications.
/// TODO: improve its efficiency.
std::vector<const RecordDecl *> getTypeAppsWithBase(const RecordDecl *Base);
Comment from @abeln:
Handle case where a struct has both a _For_any() and _Itype_for_any() specifiers (ParseDeclCXX.cpp:1650).
// Checked C - handle generic structs.
if (Tok.is(tok::kw__For_any)) {
// TODO: add error handling here.
unsigned DiagID;
const char *PrevSpec;
DS.setSpecForany(Tok.getLocation(), PrevSpec, DiagID);
ParseForanySpecifier(DS);
}
Comment from @mgrang:
@abeln Has this been fixed? If yes, please go ahead and close this bug.
Comment from @abeln:
Nope, these are still open.
Comment from @abeln:
Another TODO: handle serialization and deserialization of generic structs.
This issue was copied from https://github.com/microsoft/checkedc-clang/issues/644
This issue tracks the TODOs left during the initial implementation of generic structs (see comments below).