diff options
| author | Tim Foley <tfoleyNV@users.noreply.github.com> | 2020-02-21 08:18:31 -0800 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2020-02-21 08:18:31 -0800 |
| commit | 433ce869481b72ad44897dcc91d7038b03ba45e2 (patch) | |
| tree | d8fbe73bea7ca800485dd57b508e50c01d882a35 /source | |
| parent | 1f401d04e32c6feaeb35243ea5bfc2b14520344b (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.cpp | 67 | ||||
| -rw-r--r-- | source/slang/slang-diagnostic-defs.h | 2 |
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"); |
