summaryrefslogtreecommitdiffstats
path: root/source
diff options
context:
space:
mode:
authorTim Foley <tfoleyNV@users.noreply.github.com>2020-02-21 08:18:31 -0800
committerGitHub <noreply@github.com>2020-02-21 08:18:31 -0800
commit433ce869481b72ad44897dcc91d7038b03ba45e2 (patch)
treed8fbe73bea7ca800485dd57b508e50c01d882a35 /source
parent1f401d04e32c6feaeb35243ea5bfc2b14520344b (diff)
Initial support for explicit default initializers (#1235)
This change makes it so that for a suitable type `MyType`, a variable declaration like: MyType v; is treated as if it were written: MyType v = MyType(); The definition of "suitable" here is that `MyType` needs to have an available `__init` declaration that can be invoked with zero arguments. I've added a test to confirm that the new behavior works in this specific case. There are a bunch of caveats to the feature as it stands today: * Just because `MyType` has a zero-parameter `__init`, that doesn't mean an array type like `MyType[10]` does, so arrays currently remain uninitialized by default. Fixing this gap requires careful consideration because some, but not all, array types should be default-initializable. * The change here should mean that a `struct` type with a field like `MyType f;` should count as having a default initial-value expression for that field, but I haven't confirmed that. * Even if a `struct` provides initial values for all its fields (e.g., `struct S { float f = 0; }`), that doesn't mean it has a default `__init` right now, so those `struct` types will still be left uninitialized by default. Converging all this behavior is still TBD. Just to be clear: there is no provision or plan in Slang to support destructors, RAII, copy constructors, move constructors, overloaded assignment operations, or any other features that buy heavily into the C++ model of how construction and destruction of values gets done. In fact, I'm not even 100% sure I like having this change in place at all, and I think we should reserve the right to revert it and say that only specific stdlib types get to opt in to default initialization along these lines.
Diffstat (limited to 'source')
-rw-r--r--source/slang/slang-check-decl.cpp67
-rw-r--r--source/slang/slang-diagnostic-defs.h2
2 files changed, 69 insertions, 0 deletions
diff --git a/source/slang/slang-check-decl.cpp b/source/slang/slang-check-decl.cpp
index 99400c17c..c2b356eff 100644
--- a/source/slang/slang-check-decl.cpp
+++ b/source/slang/slang-check-decl.cpp
@@ -829,10 +829,77 @@ namespace Slang
{
if (auto initExpr = varDecl->initExpr)
{
+ // If the variable has an explicit initial-value expression,
+ // then we simply need to check that expression and coerce
+ // it to the tyep of the variable.
+ //
initExpr = CheckTerm(initExpr);
initExpr = coerce(varDecl->type.Ptr(), initExpr);
varDecl->initExpr = initExpr;
}
+ else
+ {
+ // If a variable doesn't have an explicit initial-value
+ // expression, it is still possible that it should
+ // be initialized implicitly, because the type of the
+ // variable has a default (zero parameter) initializer.
+ // That is, for types where it is possible, we will
+ // treat a variable declared like this:
+ //
+ // MyType myVar;
+ //
+ // as if it were declared as:
+ //
+ // MyType myVar = MyType();
+ //
+ // Rather than try to code up an ad hoc search for an
+ // appropriate initializer here, we will instead fall
+ // back on the general-purpose overload-resolution
+ // machinery, which can handle looking up initializers
+ // and filtering them to ones that are applicable
+ // to our "call site" with zero arguments.
+ //
+ auto type = varDecl->getType();
+
+ OverloadResolveContext overloadContext;
+ overloadContext.loc = varDecl->nameAndLoc.loc;
+ overloadContext.mode = OverloadResolveContext::Mode::JustTrying;
+ AddTypeOverloadCandidates(type, overloadContext);
+
+ if(overloadContext.bestCandidates.getCount() != 0)
+ {
+ // If there were multiple equally-good candidates to call,
+ // then might have an ambiguity.
+ //
+ // Before issuing any kind of diagnostic we need to check
+ // if any of those candidates are actually applicable,
+ // because if they aren't then we actually just have
+ // an uninitialized varaible.
+ //
+ if(overloadContext.bestCandidates[0].status != OverloadCandidate::Status::Applicable)
+ return;
+
+ getSink()->diagnose(varDecl, Diagnostics::ambiguousDefaultInitializerForType, type);
+ }
+ else if(overloadContext.bestCandidate)
+ {
+ // If we are in the single-candidate case, then we again
+ // want to ignore the case where that candidate wasn't
+ // actually applicable, because declaring a variable
+ // of a type that *doesn't* have a default initializer
+ // isn't actually an error.
+ //
+ if(overloadContext.bestCandidate->status != OverloadCandidate::Status::Applicable)
+ return;
+
+ // If we had a single best candidate *and* it was applicable,
+ // then we use it to construct a new initial-value expression
+ // for the variable, that will be used for all downstream
+ // code generation.
+ //
+ varDecl->initExpr = CompleteOverloadCandidate(overloadContext, *overloadContext.bestCandidate);
+ }
+ }
}
// Fill in default substitutions for the 'subtype' part of a type constraint decl
diff --git a/source/slang/slang-diagnostic-defs.h b/source/slang/slang-diagnostic-defs.h
index e05825aa0..06031c089 100644
--- a/source/slang/slang-diagnostic-defs.h
+++ b/source/slang/slang-diagnostic-defs.h
@@ -314,6 +314,8 @@ DIAGNOSTIC(30504, Error, cannotUseInitializerListForType, "cannot use initialize
// 306xx: variables
DIAGNOSTIC(30600, Error, varWithoutTypeMustHaveInitializer, "a variable declaration without an initial-value expression must be given an explicit type");
+DIAGNOSTIC(30610, Error, ambiguousDefaultInitializerForType, "more than one default initializer was found for type '$0'")
+
// 307xx: parameters
DIAGNOSTIC(30700, Error, outputParameterCannotHaveDefaultValue, "an 'out' or 'inout' parameter cannot have a default-value expression");