maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/utils/TableGen/LLDBPropertyDefEmitter.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

190 lines
6.9 KiB
C++
Raw Normal View History

Let tablegen generate property definitions Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly. Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums. It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058
2019-07-26 05:36:37 +08:00
//===- LLDBPropertyDefEmitter.cpp -----------------------------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
//
// These tablegen backends emits LLDB's PropertyDefinition values.
//
//===----------------------------------------------------------------------===//
#include "LLDBTableGenBackends.h"
[TableGen] Move helpers into LLDBTableGenUtils. Instead of polluting the LLDBTableGenBackends header with helpers used by both emitters, move them into a separate files. llvm-svn: 367377
2019-07-31 08:47:00 +08:00
#include "LLDBTableGenUtils.h"
Let tablegen generate property definitions Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly. Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums. It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058
2019-07-26 05:36:37 +08:00
#include "llvm/ADT/StringExtras.h"
#include "llvm/TableGen/Record.h"
#include "llvm/TableGen/StringMatcher.h"
#include "llvm/TableGen/TableGenBackend.h"
#include <vector>
using namespace llvm;
[TableGen] Reuse typedef across emitters (NFC) This moves the std::map typedef into the header so it can be reused by all the emitter implementations. llvm-svn: 367363
2019-07-31 06:50:37 +08:00
using namespace lldb_private;
Let tablegen generate property definitions Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly. Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums. It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058
2019-07-26 05:36:37 +08:00
static void emitPropertyEnum(Record *Property, raw_ostream &OS) {
OS << "eProperty";
OS << Property->getName();
OS << ",\n";
}
static void emitProperty(Record *Property, raw_ostream &OS) {
OS << " {";
// Emit the property name.
OS << "\"" << Property->getValueAsString("Name") << "\"";
OS << ", ";
// Emit the property type.
[lldb]/Tablegen] Use ElementType instead of DefaultValueUnsinged The fourth field in the property struct is the default unsigned or enum value for all types, except for Array and Dictionary types. For those, it is the element type. During the tablegen conversion, this was incorrectly translated to DefaultValueUnsigned with a value corresponding to the OptionValue: enum type. So for OptionValue::eTypeString this became DefaultUnsignedValue<16>. This patch extends the tablegen backend to understand ElementType to express this as ElementType<"String">. Differential revision: https://reviews.llvm.org/D76535
2020-03-21 09:34:50 +08:00
llvm::StringRef type = Property->getValueAsString("Type");
Let tablegen generate property definitions Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly. Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums. It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058
2019-07-26 05:36:37 +08:00
OS << "OptionValue::eType";
[lldb]/Tablegen] Use ElementType instead of DefaultValueUnsinged The fourth field in the property struct is the default unsigned or enum value for all types, except for Array and Dictionary types. For those, it is the element type. During the tablegen conversion, this was incorrectly translated to DefaultValueUnsigned with a value corresponding to the OptionValue: enum type. So for OptionValue::eTypeString this became DefaultUnsignedValue<16>. This patch extends the tablegen backend to understand ElementType to express this as ElementType<"String">. Differential revision: https://reviews.llvm.org/D76535
2020-03-21 09:34:50 +08:00
OS << type;
Let tablegen generate property definitions Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly. Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums. It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058
2019-07-26 05:36:37 +08:00
OS << ", ";
// Emit the property's global value.
OS << (Property->getValue("Global") ? "true" : "false");
OS << ", ";
bool hasDefaultUnsignedValue = Property->getValue("HasDefaultUnsignedValue");
bool hasDefaultEnumValue = Property->getValue("HasDefaultEnumValue");
bool hasDefaultStringValue = Property->getValue("HasDefaultStringValue");
[lldb]/Tablegen] Use ElementType instead of DefaultValueUnsinged The fourth field in the property struct is the default unsigned or enum value for all types, except for Array and Dictionary types. For those, it is the element type. During the tablegen conversion, this was incorrectly translated to DefaultValueUnsigned with a value corresponding to the OptionValue: enum type. So for OptionValue::eTypeString this became DefaultUnsignedValue<16>. This patch extends the tablegen backend to understand ElementType to express this as ElementType<"String">. Differential revision: https://reviews.llvm.org/D76535
2020-03-21 09:34:50 +08:00
bool hasElementType = Property->getValue("HasElementType");
Let tablegen generate property definitions Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly. Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums. It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058
2019-07-26 05:36:37 +08:00
// Guarantee that every property has a default value.
assert((hasDefaultUnsignedValue || hasDefaultEnumValue ||
[lldb]/Tablegen] Use ElementType instead of DefaultValueUnsinged The fourth field in the property struct is the default unsigned or enum value for all types, except for Array and Dictionary types. For those, it is the element type. During the tablegen conversion, this was incorrectly translated to DefaultValueUnsigned with a value corresponding to the OptionValue: enum type. So for OptionValue::eTypeString this became DefaultUnsignedValue<16>. This patch extends the tablegen backend to understand ElementType to express this as ElementType<"String">. Differential revision: https://reviews.llvm.org/D76535
2020-03-21 09:34:50 +08:00
hasDefaultStringValue || hasElementType) &&
"Property must have a default value or an element type");
Let tablegen generate property definitions Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly. Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums. It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058
2019-07-26 05:36:37 +08:00
// Guarantee that no property has both a default unsigned value and a default
// enum value, since they're bothed stored in the same field.
assert(!(hasDefaultUnsignedValue && hasDefaultEnumValue) &&
"Property cannot have both a unsigned and enum default value.");
[TableGen] Add asserts to make sure default values match property type This adds a few asserts to the property TableGen backend to prevent mismatches between property types and their default values. This would've prevented a copy-paste mistake we discovered downstream.
2019-10-26 01:17:09 +08:00
// Guarantee that every boolean property has a boolean default value.
assert(!(Property->getValueAsString("Type") == "Boolean" &&
[LLDB] Fix inline variable only used in assertion. (NFC) This prevents unused variable warning/error in -DNDEBUG builds. The variable was introduced in 5934cd11ea3e. Patch by: Shu-Chun Weng Differential revision: https://reviews.llvm.org/D69451
2019-10-26 06:46:24 +08:00
!Property->getValue("HasDefaultBooleanValue")) &&
[TableGen] Add asserts to make sure default values match property type This adds a few asserts to the property TableGen backend to prevent mismatches between property types and their default values. This would've prevented a copy-paste mistake we discovered downstream.
2019-10-26 01:17:09 +08:00
"Boolean property must have a boolean default value.");
// Guarantee that every string property has a string default value.
assert(!(Property->getValueAsString("Type") == "String" &&
!hasDefaultStringValue) &&
"String property must have a string default value.");
// Guarantee that every enum property has an enum default value.
assert(
!(Property->getValueAsString("Type") == "Enum" && !hasDefaultEnumValue) &&
"Enum property must have a enum default value.");
[lldb]/Tablegen] Use ElementType instead of DefaultValueUnsinged The fourth field in the property struct is the default unsigned or enum value for all types, except for Array and Dictionary types. For those, it is the element type. During the tablegen conversion, this was incorrectly translated to DefaultValueUnsigned with a value corresponding to the OptionValue: enum type. So for OptionValue::eTypeString this became DefaultUnsignedValue<16>. This patch extends the tablegen backend to understand ElementType to express this as ElementType<"String">. Differential revision: https://reviews.llvm.org/D76535
2020-03-21 09:34:50 +08:00
// Guarantee that only arrays and dictionaries have an element type;
assert(((type != "Array" && type != "Dictionary") || hasElementType) &&
"Only dictionaries and arrays can have an element type.");
Let tablegen generate property definitions Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly. Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums. It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058
2019-07-26 05:36:37 +08:00
// Emit the default uint value.
if (hasDefaultUnsignedValue) {
OS << std::to_string(Property->getValueAsInt("DefaultUnsignedValue"));
} else if (hasDefaultEnumValue) {
OS << Property->getValueAsString("DefaultEnumValue");
[lldb]/Tablegen] Use ElementType instead of DefaultValueUnsinged The fourth field in the property struct is the default unsigned or enum value for all types, except for Array and Dictionary types. For those, it is the element type. During the tablegen conversion, this was incorrectly translated to DefaultValueUnsigned with a value corresponding to the OptionValue: enum type. So for OptionValue::eTypeString this became DefaultUnsignedValue<16>. This patch extends the tablegen backend to understand ElementType to express this as ElementType<"String">. Differential revision: https://reviews.llvm.org/D76535
2020-03-21 09:34:50 +08:00
} else if (hasElementType) {
OS << "OptionValue::eType";
OS << Property->getValueAsString("ElementType");
Let tablegen generate property definitions Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly. Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums. It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058
2019-07-26 05:36:37 +08:00
} else {
OS << "0";
}
OS << ", ";
// Emit the default string value.
if (hasDefaultStringValue) {
if (auto D = Property->getValue("DefaultStringValue")) {
OS << "\"";
[Tablegen] Fix issues caused by incorrect escaping. The printEscapedString would escape newlines by their ASCII values instead of prefixing them with a `\`. Remove the escaping logic and escape the strings in the definition file. llvm-svn: 367065
2019-07-26 06:17:08 +08:00
OS << D->getValue()->getAsUnquotedString();
Let tablegen generate property definitions Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly. Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums. It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058
2019-07-26 05:36:37 +08:00
OS << "\"";
} else {
OS << "\"\"";
}
} else {
OS << "nullptr";
}
OS << ", ";
// Emit the enum values value.
if (Property->getValue("EnumValues"))
OS << Property->getValueAsString("EnumValues");
else
OS << "{}";
OS << ", ";
// Emit the property description.
if (auto D = Property->getValue("Description")) {
OS << "\"";
[Tablegen] Fix issues caused by incorrect escaping. The printEscapedString would escape newlines by their ASCII values instead of prefixing them with a `\`. Remove the escaping logic and escape the strings in the definition file. llvm-svn: 367065
2019-07-26 06:17:08 +08:00
OS << D->getValue()->getAsUnquotedString();
Let tablegen generate property definitions Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly. Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums. It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058
2019-07-26 05:36:37 +08:00
OS << "\"";
} else {
OS << "\"\"";
}
OS << "},\n";
}
/// Emits all property initializers to the raw_ostream.
static void emityProperties(std::string PropertyName,
std::vector<Record *> PropertyRecords,
raw_ostream &OS) {
// Generate the macro that the user needs to define before including the
// *.inc file.
std::string NeededMacro = "LLDB_PROPERTIES_" + PropertyName;
std::replace(NeededMacro.begin(), NeededMacro.end(), ' ', '_');
// All options are in one file, so we need put them behind macros and ask the
// user to define the macro for the options that are needed.
OS << "// Property definitions for " << PropertyName << "\n";
OS << "#ifdef " << NeededMacro << "\n";
[lldb] Also include the array definition in Properties.inc Right now our Properties.inc only generates the initializer for the options list but not the array declaration boilerplate around it. As the array definition is identical for all arrays, we might as well also let the Properties.inc generate it alongside the initializers. Unfortunately we cannot do the same for enums, as there's this magic ePropertyExperimental, which needs to come at the end to be interpreted correctly. Hopefully we can get rid of this in the future and do the same for the property enums. Differential revision: https://reviews.llvm.org/D65353 llvm-svn: 367238
2019-07-30 00:41:30 +08:00
OS << "static constexpr PropertyDefinition g_" << PropertyName
<< "_properties[] = {\n";
Let tablegen generate property definitions Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly. Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums. It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058
2019-07-26 05:36:37 +08:00
for (Record *R : PropertyRecords)
emitProperty(R, OS);
[lldb] Also include the array definition in Properties.inc Right now our Properties.inc only generates the initializer for the options list but not the array declaration boilerplate around it. As the array definition is identical for all arrays, we might as well also let the Properties.inc generate it alongside the initializers. Unfortunately we cannot do the same for enums, as there's this magic ePropertyExperimental, which needs to come at the end to be interpreted correctly. Hopefully we can get rid of this in the future and do the same for the property enums. Differential revision: https://reviews.llvm.org/D65353 llvm-svn: 367238
2019-07-30 00:41:30 +08:00
OS << "};\n";
Let tablegen generate property definitions Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly. Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums. It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058
2019-07-26 05:36:37 +08:00
// We undefine the macro for the user like Clang's include files are doing it.
OS << "#undef " << NeededMacro << "\n";
OS << "#endif // " << PropertyName << " Property\n\n";
}
/// Emits all property initializers to the raw_ostream.
static void emitPropertyEnum(std::string PropertyName,
std::vector<Record *> PropertyRecords,
raw_ostream &OS) {
// Generate the macro that the user needs to define before including the
// *.inc file.
std::string NeededMacro = "LLDB_PROPERTIES_" + PropertyName;
std::replace(NeededMacro.begin(), NeededMacro.end(), ' ', '_');
// All options are in one file, so we need put them behind macros and ask the
// user to define the macro for the options that are needed.
OS << "// Property enum cases for " << PropertyName << "\n";
OS << "#ifdef " << NeededMacro << "\n";
for (Record *R : PropertyRecords)
emitPropertyEnum(R, OS);
// We undefine the macro for the user like Clang's include files are doing it.
OS << "#undef " << NeededMacro << "\n";
OS << "#endif // " << PropertyName << " Property\n\n";
}
void lldb_private::EmitPropertyDefs(RecordKeeper &Records, raw_ostream &OS) {
emitSourceFileHeader("Property definitions for LLDB.", OS);
std::vector<Record *> Properties =
Records.getAllDerivedDefinitions("Property");
[TableGen] Move helpers into LLDBTableGenUtils. Instead of polluting the LLDBTableGenBackends header with helpers used by both emitters, move them into a separate files. llvm-svn: 367377
2019-07-31 08:47:00 +08:00
for (auto &PropertyRecordPair : getRecordsByName(Properties, "Definition")) {
Let tablegen generate property definitions Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly. Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums. It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058
2019-07-26 05:36:37 +08:00
emityProperties(PropertyRecordPair.first, PropertyRecordPair.second, OS);
}
}
void lldb_private::EmitPropertyEnumDefs(RecordKeeper &Records,
raw_ostream &OS) {
emitSourceFileHeader("Property definition enum for LLDB.", OS);
std::vector<Record *> Properties =
Records.getAllDerivedDefinitions("Property");
[TableGen] Move helpers into LLDBTableGenUtils. Instead of polluting the LLDBTableGenBackends header with helpers used by both emitters, move them into a separate files. llvm-svn: 367377
2019-07-31 08:47:00 +08:00
for (auto &PropertyRecordPair : getRecordsByName(Properties, "Definition")) {
Let tablegen generate property definitions Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly. Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums. It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058
2019-07-26 05:36:37 +08:00
emitPropertyEnum(PropertyRecordPair.first, PropertyRecordPair.second, OS);
}
}