[QoL][IR] Provide default constructor for NameSupply/GlobalVarSupply #17135
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Prior to this commit, a
tvm::NameSupply
needed to be constructed with an explicitconst String& prefix
argument. Omitting this argument would fall back to the default constructor provided by theTVM_DEFINE_MUTABLE_OBJECT_REF_METHODS
macro, producing aNameSupply
holding a nullptr. This then leads to a segfault when the nullNameSupply
is used.The vast majority of usages of
NameSupply::NameSupply
(29 out of 31) initialize it with an emptyprefix
string. The remaining two use cases initialize it with a non-emptyprefix
string. There are no cases in which a nullNameSupply
is initialized.This commit updates
NameSupply
to use theTVM_DEFINE_MUTABLE_NOTNULLABLE_OBJECT_REF_METHODS
macro instead ofTVM_DEFINE_MUTABLE_OBJECT_REF_METHODS
. This allows the default constructor to provide the common usage of aNameSupply
with an empty prefix, rather than the error-prone usage of a nullNameSupply
A similar change is also made for
GlobalVarSupply
, as the majority of its uses also default to an empty prefix (11 out of 13).