Commit 489ffc4d by Jamie Madill

Allow varying structs to match between stages.

We would always expand a struct name to always include its symbol ID. This workaround fixed scoped structs with the same name. It would also block any possiblity of linking the structs successfully. Instead we can use the workaround only on inner-scoped structs, and leave global structs, which are by definition uniquely named, as they are. This fixes several tests in dEQP's shader.linkage.varying.struct. BUG=angle:910 Change-Id: I81b8dadc7ea493152aff0c44d607114eaaabb142 Reviewed-on: https://chromium-review.googlesource.com/247242Reviewed-by: 's avatarGeoff Lang <geofflang@chromium.org> Tested-by: 's avatarJamie Madill <jmadill@chromium.org>
parent 2857f489
......@@ -2545,7 +2545,12 @@ TPublicType TParseContext::addStructure(const TSourceLoc& structLine, const TSou
TStructure* structure = new TStructure(structName, fieldList);
TType* structureType = new TType(structure);
structure->setUniqueId(TSymbolTable::nextUniqueId());
// Check for global struct, and do not assign an ID if so, to prevent us from
// rewriting the struct name to avoid scoping conflicts.
if (!symbolTable.atGlobalLevel())
{
structure->setUniqueId(TSymbolTable::nextUniqueId());
}
if (!structName->empty())
{
......
......@@ -134,7 +134,6 @@ class TStructure : public TFieldListCollection
int uniqueId() const
{
ASSERT(mUniqueId != 0);
return mUniqueId;
}
......
......@@ -175,6 +175,13 @@ TString StructNameString(const TStructure &structure)
return "";
}
// For structures at global scope (tagged with ID 0) we use a consistent
// translation so that we can link varying structs.
if (structure.uniqueId() == 0)
{
return Decorate(structure.name());
}
return "ss" + str(structure.uniqueId()) + "_" + structure.name();
}
......
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment