Lexically scoped child resources #1516
Conversation
rynowak
force-pushed
the
rynowak/lexical-nesting
branch
from
8362edc to
9133b4c
Compare
Codecov Report
@@ Coverage Diff @@
## main #1516 +/- ##
==========================================
- Coverage 95.26% 95.08% -0.18%
==========================================
Files 364 370 +6
Lines 20455 21379 +924
Branches 15 15
==========================================
+ Hits 19486 20328 +842
- Misses 969 1051 +82
Flags with carried forward coverage won't be shown. Click here to find out more.
|
rynowak
force-pushed
the
rynowak/lexical-nesting
branch
from
9133b4c to
46a7009
Compare
rynowak
force-pushed
the
rynowak/lexical-nesting
branch
2 times, most recently
from
f490edf to
2188cce
Compare
rynowak
force-pushed
the
rynowak/lexical-nesting
branch
3 times, most recently
from
f7a4879 to
6ce2fb2
Compare
|
There's something going on with property access completions. Starting with this file: resource vnet 'Microsoft.Network/virtualNetworks@2020-06-01' = {
resource subnet 'subnets' = {
name: 'test'
}
}
resource subnet2 'Microsoft.Network/virtualNetworks/subnets@2020-06-01' = {
}
output hmm string = subnet2.properties.
output hmmmm string = vnet:subnet.properties.There's a difference in completions offered. Standalone subnet: Nested subnet: |
| else if (symbol is null || symbol is not ResourceSymbol) | ||
| { | ||
| // symbol could be null in the case of an incomplete expression during parsing like `a:` | ||
| var error = new ErrorSymbol(DiagnosticBuilder.ForPosition(syntax.ResourceName).ResourceRequiredForResourceAccess(symbol?.Kind.ToString() ?? LanguageConstants.ErrorName)); |
There was a problem hiding this comment.
Should the error span be on the base expression? The root cause of the error is the fact that the base expression isn't bound to a resource symbol. On the other hand, the squiggle would cover the entire base expression, which could get kind of nasty if the expression is complicated.
What do you think?
There was a problem hiding this comment.
what about on the colon? The error in this case is the operator you're using - which doesn't apply to the type on the LHS. Or is that too subtle?
Where would the span be for something like:
var test = 42
var wrong = 42.foo
There was a problem hiding this comment.
For the above, we do this:
Yeah I think : would be too subtle but it is also one of the possible causes of the error. I guess for consistency we could leave it where it is.
There was a problem hiding this comment.
FYI what I'm doing here is consistent with property access on a non-object type. I'm going to leave it for now unless there's a strong reason to revisit.
rynowak
force-pushed
the
rynowak/lexical-nesting
branch
2 times, most recently
from
9f20a88 to
51c32ae
Compare
Fixed this issue. There was a problem with declared type assignment for resource access. Property completion expects the resource body type, and I was assigning the resource type. |
|
@anthony-c-martin @majastrz - updated |
rynowak
force-pushed
the
rynowak/lexical-nesting
branch
from
b2bce85 to
bfc0c44
Compare
|
@anthony-c-martin @majastrz - know what's up with the failing build? Other than that should be ready to go. |
Fixes: Azure#1363 This change add support for lexical scoping/nesting of child resources. That it, for a resource type: `My.RP/someType@2020-01-01` there's now a simplified syntax for including a resource: `My.RP/someType/childType@2020-01-01` inside the body of the parent. This syntax also allows simplication of the type name of the child, limits its scope/visibility and implies an automatic `dependsOn` to the parent resource. The goal is to be the most idiomatic way to declare multiple resources to be deployed with a parent/child/grandchild/etc relationship. This also includes the new "nested resource access" operator which allows lookup of a nested resource: ``` output someOutput string = parent:child.properties.size ``
rynowak
force-pushed
the
rynowak/lexical-nesting
branch
from
ed21c97 to
a58e509
Compare
Fixes: #1363
This change add support for lexical scoping/nesting of child resources.
That it, for a resource type:
My.RP/someType@2020-01-01there's now asimplified syntax for including a resource:
My.RP/someType/childType@2020-01-01inside the body of the parent.This syntax also allows simplication of the type name of the child,
limits its scope/visibility and implies an automatic
dependsOnto theparent resource. The goal is to be the most idiomatic way to declare
multiple resources to be deployed with a parent/child/grandchild/etc
relationship.
This also includes the new "nested resource access" operator which
allows lookup of a nested resource:
I still need to:
resourcekeyword inside anObjectSyntax:into a commit character for variables when the completion refers to a resource nameLanguageExpressioninstead of syntaxContributing a feature