2015-01-23 23:15:10 +01:00
|
|
|
// Copyright 2014 Google Inc. All rights reserved.
|
|
|
|
//
|
|
|
|
// Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
// you may not use this file except in compliance with the License.
|
|
|
|
// You may obtain a copy of the License at
|
|
|
|
//
|
|
|
|
// http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
//
|
|
|
|
// Unless required by applicable law or agreed to in writing, software
|
|
|
|
// distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
// See the License for the specific language governing permissions and
|
|
|
|
// limitations under the License.
|
|
|
|
|
2015-01-09 04:35:10 +01:00
|
|
|
package parser
|
|
|
|
|
|
|
|
import (
|
|
|
|
"bytes"
|
|
|
|
"testing"
|
|
|
|
)
|
|
|
|
|
|
|
|
var validPrinterTestCases = []struct {
|
Select statements
Select statements are a new blueprint feature inspired by bazel's select
statements. They are essentially alternative syntax for soong config
variables that require less boilerplate. In addition, they support
making decisions based on a module's variant, which will eliminate
the need for manual property struct manipulation, such as the arch
mutator's arch: and target: properties.
In order to support decisions based on the variant, select statements
cannot be evaluated as soon as they're parsed. Instead, they must be
stored in the property struct unevaluated. This means that individual
properties need to change their type from say, string, to
Configurable[string]. Currently, only configurable strings, bools, and
string slices are supported, but more types can be added later.
The module implementation must call my_property.Evaluate(ctx) in order
to get the final, resolved value of the select statement.
Bug: 323382414
Test: go tests
Change-Id: I62f8721d7f0ac3d1df4a06d7eaa260a5aa7fcba3
2024-02-02 02:44:27 +01:00
|
|
|
name string
|
2015-01-09 04:35:10 +01:00
|
|
|
input string
|
|
|
|
output string
|
|
|
|
}{
|
|
|
|
{
|
|
|
|
input: `
|
2015-03-03 00:32:36 +01:00
|
|
|
foo {}
|
2015-01-09 04:35:10 +01:00
|
|
|
`,
|
|
|
|
output: `
|
2015-03-03 00:32:36 +01:00
|
|
|
foo {}
|
2015-01-09 04:35:10 +01:00
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
2018-06-25 05:52:48 +02:00
|
|
|
foo(name= "abc",num= 4,)
|
2015-01-09 04:35:10 +01:00
|
|
|
`,
|
|
|
|
output: `
|
2015-03-03 00:32:36 +01:00
|
|
|
foo {
|
|
|
|
name: "abc",
|
Support parsing int64 in Blueprint file.
Support int64 number instead of int to be more fixed to bit size so
that the underlying arch won't affect overflow cases. Besides,
refection: func (v Value) Int() int64 always cast to int64 no matter the
input is int, int16, int32. Currently we always treat "-" as negative
sign to bind to next value, and "+" as plus operator to add operands
together.
So we allow:
a = 5 + -4 + 5 or a = -4 + 5
But we don't allow:
a = +5 + 4 + -4 since we don't treat "+" as a positive sign, otherwise,
a = 5 + +5 would exist which looks pretty weird. In the future, we may
want fully support number calculator logic eg, "+"/"-" can be
positive/negative sign or operator, and "(" and ")" will be considered
to group expressions with a higher precedence.
int & uint properties within struct keeps unchanged, which is only
allowed when tagged with 'blueprint:mutated'. We only allow *int64
property instead of int64 property within struct since it does't make
sense to do prepending or appending to int64.
Change-Id: I565e046dbd268af3538aee148cd7300037e56523
2017-11-01 22:03:28 +01:00
|
|
|
num: 4,
|
2015-03-03 00:32:36 +01:00
|
|
|
}
|
2015-01-09 04:35:10 +01:00
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
2015-03-03 00:32:36 +01:00
|
|
|
foo {
|
|
|
|
stuff: ["asdf", "jkl;", "qwert",
|
2015-01-09 04:35:10 +01:00
|
|
|
"uiop", "bnm,"]
|
2015-03-03 00:32:36 +01:00
|
|
|
}
|
2015-01-09 04:35:10 +01:00
|
|
|
`,
|
|
|
|
output: `
|
2015-03-03 00:32:36 +01:00
|
|
|
foo {
|
|
|
|
stuff: [
|
2015-01-09 04:35:10 +01:00
|
|
|
"asdf",
|
|
|
|
"bnm,",
|
|
|
|
"jkl;",
|
|
|
|
"qwert",
|
|
|
|
"uiop",
|
|
|
|
],
|
2015-03-03 00:32:36 +01:00
|
|
|
}
|
2016-06-07 21:28:16 +02:00
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
|
|
|
var = "asdf"
|
|
|
|
foo {
|
|
|
|
stuff: ["asdf"] + var,
|
|
|
|
}`,
|
|
|
|
output: `
|
|
|
|
var = "asdf"
|
|
|
|
foo {
|
|
|
|
stuff: ["asdf"] + var,
|
|
|
|
}
|
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
|
|
|
var = "asdf"
|
|
|
|
foo {
|
|
|
|
stuff: [
|
|
|
|
"asdf"
|
|
|
|
] + var,
|
|
|
|
}`,
|
|
|
|
output: `
|
|
|
|
var = "asdf"
|
|
|
|
foo {
|
|
|
|
stuff: [
|
|
|
|
"asdf",
|
|
|
|
] + var,
|
|
|
|
}
|
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
|
|
|
var = "asdf"
|
|
|
|
foo {
|
|
|
|
stuff: ["asdf"] + var + ["qwert"],
|
|
|
|
}`,
|
|
|
|
output: `
|
|
|
|
var = "asdf"
|
|
|
|
foo {
|
|
|
|
stuff: ["asdf"] + var + ["qwert"],
|
|
|
|
}
|
2015-01-09 04:35:10 +01:00
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
2015-03-03 00:32:36 +01:00
|
|
|
foo {
|
|
|
|
stuff: {
|
2015-01-09 04:35:10 +01:00
|
|
|
isGood: true,
|
Support parsing int64 in Blueprint file.
Support int64 number instead of int to be more fixed to bit size so
that the underlying arch won't affect overflow cases. Besides,
refection: func (v Value) Int() int64 always cast to int64 no matter the
input is int, int16, int32. Currently we always treat "-" as negative
sign to bind to next value, and "+" as plus operator to add operands
together.
So we allow:
a = 5 + -4 + 5 or a = -4 + 5
But we don't allow:
a = +5 + 4 + -4 since we don't treat "+" as a positive sign, otherwise,
a = 5 + +5 would exist which looks pretty weird. In the future, we may
want fully support number calculator logic eg, "+"/"-" can be
positive/negative sign or operator, and "(" and ")" will be considered
to group expressions with a higher precedence.
int & uint properties within struct keeps unchanged, which is only
allowed when tagged with 'blueprint:mutated'. We only allow *int64
property instead of int64 property within struct since it does't make
sense to do prepending or appending to int64.
Change-Id: I565e046dbd268af3538aee148cd7300037e56523
2017-11-01 22:03:28 +01:00
|
|
|
name: "bar",
|
|
|
|
num: 4,
|
2015-01-09 04:35:10 +01:00
|
|
|
}
|
2015-03-03 00:32:36 +01:00
|
|
|
}
|
2015-01-09 04:35:10 +01:00
|
|
|
`,
|
|
|
|
output: `
|
2015-03-03 00:32:36 +01:00
|
|
|
foo {
|
|
|
|
stuff: {
|
2015-01-09 04:35:10 +01:00
|
|
|
isGood: true,
|
|
|
|
name: "bar",
|
Support parsing int64 in Blueprint file.
Support int64 number instead of int to be more fixed to bit size so
that the underlying arch won't affect overflow cases. Besides,
refection: func (v Value) Int() int64 always cast to int64 no matter the
input is int, int16, int32. Currently we always treat "-" as negative
sign to bind to next value, and "+" as plus operator to add operands
together.
So we allow:
a = 5 + -4 + 5 or a = -4 + 5
But we don't allow:
a = +5 + 4 + -4 since we don't treat "+" as a positive sign, otherwise,
a = 5 + +5 would exist which looks pretty weird. In the future, we may
want fully support number calculator logic eg, "+"/"-" can be
positive/negative sign or operator, and "(" and ")" will be considered
to group expressions with a higher precedence.
int & uint properties within struct keeps unchanged, which is only
allowed when tagged with 'blueprint:mutated'. We only allow *int64
property instead of int64 property within struct since it does't make
sense to do prepending or appending to int64.
Change-Id: I565e046dbd268af3538aee148cd7300037e56523
2017-11-01 22:03:28 +01:00
|
|
|
num: 4,
|
2015-01-09 04:35:10 +01:00
|
|
|
},
|
2015-03-03 00:32:36 +01:00
|
|
|
}
|
2015-01-09 04:35:10 +01:00
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
|
|
|
// comment1
|
2015-03-03 00:32:36 +01:00
|
|
|
foo {
|
2015-01-09 04:35:10 +01:00
|
|
|
// comment2
|
2015-03-03 00:32:36 +01:00
|
|
|
isGood: true, // comment3
|
|
|
|
}
|
2015-01-09 04:35:10 +01:00
|
|
|
`,
|
|
|
|
output: `
|
|
|
|
// comment1
|
2015-03-03 00:32:36 +01:00
|
|
|
foo {
|
2015-01-09 04:35:10 +01:00
|
|
|
// comment2
|
2015-03-03 00:32:36 +01:00
|
|
|
isGood: true, // comment3
|
|
|
|
}
|
2015-01-09 04:35:10 +01:00
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
2015-03-03 00:32:36 +01:00
|
|
|
foo {
|
|
|
|
name: "abc",
|
Support parsing int64 in Blueprint file.
Support int64 number instead of int to be more fixed to bit size so
that the underlying arch won't affect overflow cases. Besides,
refection: func (v Value) Int() int64 always cast to int64 no matter the
input is int, int16, int32. Currently we always treat "-" as negative
sign to bind to next value, and "+" as plus operator to add operands
together.
So we allow:
a = 5 + -4 + 5 or a = -4 + 5
But we don't allow:
a = +5 + 4 + -4 since we don't treat "+" as a positive sign, otherwise,
a = 5 + +5 would exist which looks pretty weird. In the future, we may
want fully support number calculator logic eg, "+"/"-" can be
positive/negative sign or operator, and "(" and ")" will be considered
to group expressions with a higher precedence.
int & uint properties within struct keeps unchanged, which is only
allowed when tagged with 'blueprint:mutated'. We only allow *int64
property instead of int64 property within struct since it does't make
sense to do prepending or appending to int64.
Change-Id: I565e046dbd268af3538aee148cd7300037e56523
2017-11-01 22:03:28 +01:00
|
|
|
num: 4,
|
2015-03-03 00:32:36 +01:00
|
|
|
}
|
2015-01-09 04:35:10 +01:00
|
|
|
|
2015-03-03 00:32:36 +01:00
|
|
|
bar {
|
|
|
|
name: "def",
|
Support parsing int64 in Blueprint file.
Support int64 number instead of int to be more fixed to bit size so
that the underlying arch won't affect overflow cases. Besides,
refection: func (v Value) Int() int64 always cast to int64 no matter the
input is int, int16, int32. Currently we always treat "-" as negative
sign to bind to next value, and "+" as plus operator to add operands
together.
So we allow:
a = 5 + -4 + 5 or a = -4 + 5
But we don't allow:
a = +5 + 4 + -4 since we don't treat "+" as a positive sign, otherwise,
a = 5 + +5 would exist which looks pretty weird. In the future, we may
want fully support number calculator logic eg, "+"/"-" can be
positive/negative sign or operator, and "(" and ")" will be considered
to group expressions with a higher precedence.
int & uint properties within struct keeps unchanged, which is only
allowed when tagged with 'blueprint:mutated'. We only allow *int64
property instead of int64 property within struct since it does't make
sense to do prepending or appending to int64.
Change-Id: I565e046dbd268af3538aee148cd7300037e56523
2017-11-01 22:03:28 +01:00
|
|
|
num: 5,
|
2015-03-03 00:32:36 +01:00
|
|
|
}
|
2015-01-09 04:35:10 +01:00
|
|
|
`,
|
|
|
|
output: `
|
2015-03-03 00:32:36 +01:00
|
|
|
foo {
|
|
|
|
name: "abc",
|
Support parsing int64 in Blueprint file.
Support int64 number instead of int to be more fixed to bit size so
that the underlying arch won't affect overflow cases. Besides,
refection: func (v Value) Int() int64 always cast to int64 no matter the
input is int, int16, int32. Currently we always treat "-" as negative
sign to bind to next value, and "+" as plus operator to add operands
together.
So we allow:
a = 5 + -4 + 5 or a = -4 + 5
But we don't allow:
a = +5 + 4 + -4 since we don't treat "+" as a positive sign, otherwise,
a = 5 + +5 would exist which looks pretty weird. In the future, we may
want fully support number calculator logic eg, "+"/"-" can be
positive/negative sign or operator, and "(" and ")" will be considered
to group expressions with a higher precedence.
int & uint properties within struct keeps unchanged, which is only
allowed when tagged with 'blueprint:mutated'. We only allow *int64
property instead of int64 property within struct since it does't make
sense to do prepending or appending to int64.
Change-Id: I565e046dbd268af3538aee148cd7300037e56523
2017-11-01 22:03:28 +01:00
|
|
|
num: 4,
|
2015-03-03 00:32:36 +01:00
|
|
|
}
|
2015-01-09 04:35:10 +01:00
|
|
|
|
2015-03-03 00:32:36 +01:00
|
|
|
bar {
|
|
|
|
name: "def",
|
Support parsing int64 in Blueprint file.
Support int64 number instead of int to be more fixed to bit size so
that the underlying arch won't affect overflow cases. Besides,
refection: func (v Value) Int() int64 always cast to int64 no matter the
input is int, int16, int32. Currently we always treat "-" as negative
sign to bind to next value, and "+" as plus operator to add operands
together.
So we allow:
a = 5 + -4 + 5 or a = -4 + 5
But we don't allow:
a = +5 + 4 + -4 since we don't treat "+" as a positive sign, otherwise,
a = 5 + +5 would exist which looks pretty weird. In the future, we may
want fully support number calculator logic eg, "+"/"-" can be
positive/negative sign or operator, and "(" and ")" will be considered
to group expressions with a higher precedence.
int & uint properties within struct keeps unchanged, which is only
allowed when tagged with 'blueprint:mutated'. We only allow *int64
property instead of int64 property within struct since it does't make
sense to do prepending or appending to int64.
Change-Id: I565e046dbd268af3538aee148cd7300037e56523
2017-11-01 22:03:28 +01:00
|
|
|
num: 5,
|
2015-03-03 00:32:36 +01:00
|
|
|
}
|
2018-05-08 01:11:42 +02:00
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
|
|
|
foo {
|
|
|
|
bar: "b" +
|
|
|
|
"a" +
|
|
|
|
"z",
|
|
|
|
}
|
|
|
|
`,
|
|
|
|
output: `
|
|
|
|
foo {
|
|
|
|
bar: "b" +
|
|
|
|
"a" +
|
|
|
|
"z",
|
|
|
|
}
|
2015-01-09 04:35:10 +01:00
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
|
|
|
foo = "stuff"
|
|
|
|
bar = foo
|
|
|
|
baz = foo + bar
|
2015-02-04 19:50:22 +01:00
|
|
|
baz += foo
|
2015-01-09 04:35:10 +01:00
|
|
|
`,
|
|
|
|
output: `
|
|
|
|
foo = "stuff"
|
|
|
|
bar = foo
|
|
|
|
baz = foo + bar
|
2015-02-04 19:50:22 +01:00
|
|
|
baz += foo
|
Support parsing int64 in Blueprint file.
Support int64 number instead of int to be more fixed to bit size so
that the underlying arch won't affect overflow cases. Besides,
refection: func (v Value) Int() int64 always cast to int64 no matter the
input is int, int16, int32. Currently we always treat "-" as negative
sign to bind to next value, and "+" as plus operator to add operands
together.
So we allow:
a = 5 + -4 + 5 or a = -4 + 5
But we don't allow:
a = +5 + 4 + -4 since we don't treat "+" as a positive sign, otherwise,
a = 5 + +5 would exist which looks pretty weird. In the future, we may
want fully support number calculator logic eg, "+"/"-" can be
positive/negative sign or operator, and "(" and ")" will be considered
to group expressions with a higher precedence.
int & uint properties within struct keeps unchanged, which is only
allowed when tagged with 'blueprint:mutated'. We only allow *int64
property instead of int64 property within struct since it does't make
sense to do prepending or appending to int64.
Change-Id: I565e046dbd268af3538aee148cd7300037e56523
2017-11-01 22:03:28 +01:00
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
|
|
|
foo = 100
|
|
|
|
bar = foo
|
|
|
|
baz = foo + bar
|
|
|
|
baz += foo
|
|
|
|
`,
|
|
|
|
output: `
|
|
|
|
foo = 100
|
|
|
|
bar = foo
|
|
|
|
baz = foo + bar
|
|
|
|
baz += foo
|
2018-05-08 01:11:42 +02:00
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
|
|
|
foo = "bar " +
|
|
|
|
"" +
|
|
|
|
"baz"
|
|
|
|
`,
|
|
|
|
output: `
|
|
|
|
foo = "bar " +
|
|
|
|
"" +
|
|
|
|
"baz"
|
2015-01-09 04:35:10 +01:00
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
|
|
|
//test
|
2015-03-03 00:32:36 +01:00
|
|
|
test /* test */ {
|
|
|
|
srcs: [
|
2015-03-21 03:39:29 +01:00
|
|
|
/*"bootstrap/bootstrap.go",
|
|
|
|
"bootstrap/cleanup.go",*/
|
|
|
|
"bootstrap/command.go",
|
|
|
|
"bootstrap/doc.go", //doc.go
|
|
|
|
"bootstrap/config.go", //config.go
|
2015-01-09 04:35:10 +01:00
|
|
|
],
|
2015-03-03 00:32:36 +01:00
|
|
|
deps: ["libabc"],
|
|
|
|
incs: []
|
|
|
|
} //test
|
2015-01-09 04:35:10 +01:00
|
|
|
//test
|
2015-03-03 00:32:36 +01:00
|
|
|
test2 {
|
|
|
|
}
|
2015-01-09 04:35:10 +01:00
|
|
|
|
|
|
|
|
|
|
|
//test3
|
|
|
|
`,
|
|
|
|
output: `
|
|
|
|
//test
|
2015-03-03 00:32:36 +01:00
|
|
|
test /* test */ {
|
|
|
|
srcs: [
|
2015-03-21 03:39:29 +01:00
|
|
|
/*"bootstrap/bootstrap.go",
|
|
|
|
"bootstrap/cleanup.go",*/
|
|
|
|
"bootstrap/command.go",
|
|
|
|
"bootstrap/config.go", //config.go
|
|
|
|
"bootstrap/doc.go", //doc.go
|
2015-01-09 04:35:10 +01:00
|
|
|
],
|
2015-03-03 00:32:36 +01:00
|
|
|
deps: ["libabc"],
|
|
|
|
incs: [],
|
|
|
|
} //test
|
2015-01-09 04:35:10 +01:00
|
|
|
//test
|
2016-06-11 02:27:12 +02:00
|
|
|
|
2015-03-03 00:32:36 +01:00
|
|
|
test2 {
|
|
|
|
}
|
2015-01-09 04:35:10 +01:00
|
|
|
|
|
|
|
//test3
|
2015-01-31 01:38:08 +01:00
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
|
|
|
// test
|
|
|
|
module // test
|
|
|
|
|
2015-03-03 00:32:36 +01:00
|
|
|
{
|
2015-01-31 01:38:08 +01:00
|
|
|
srcs
|
2015-03-03 00:32:36 +01:00
|
|
|
: [
|
2015-01-31 01:38:08 +01:00
|
|
|
"src1.c",
|
|
|
|
"src2.c",
|
|
|
|
],
|
|
|
|
//test
|
2015-03-03 00:32:36 +01:00
|
|
|
}
|
2015-01-31 01:38:08 +01:00
|
|
|
//test2
|
|
|
|
`,
|
|
|
|
output: `
|
|
|
|
// test
|
2015-03-03 00:32:36 +01:00
|
|
|
module { // test
|
|
|
|
srcs: [
|
2015-01-31 01:38:08 +01:00
|
|
|
"src1.c",
|
|
|
|
"src2.c",
|
|
|
|
],
|
|
|
|
//test
|
2015-03-03 00:32:36 +01:00
|
|
|
}
|
2015-03-19 22:49:38 +01:00
|
|
|
|
2015-01-31 01:38:08 +01:00
|
|
|
//test2
|
2015-03-19 22:49:38 +01:00
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
|
|
|
/*test {
|
|
|
|
test: true,
|
|
|
|
}*/
|
|
|
|
|
|
|
|
test {
|
|
|
|
/*test: true,*/
|
|
|
|
}
|
|
|
|
|
|
|
|
// This
|
2016-06-11 02:27:12 +02:00
|
|
|
/* Is *//* A */ // A
|
2015-03-19 22:49:38 +01:00
|
|
|
// A
|
|
|
|
|
|
|
|
// Multiline
|
|
|
|
// Comment
|
|
|
|
|
|
|
|
test {}
|
|
|
|
|
|
|
|
// This
|
|
|
|
/* Is */
|
|
|
|
// A
|
|
|
|
// Trailing
|
|
|
|
|
|
|
|
// Multiline
|
|
|
|
// Comment
|
|
|
|
`,
|
|
|
|
output: `
|
|
|
|
/*test {
|
|
|
|
test: true,
|
|
|
|
}*/
|
|
|
|
|
|
|
|
test {
|
|
|
|
/*test: true,*/
|
|
|
|
}
|
|
|
|
|
|
|
|
// This
|
2016-06-11 02:27:12 +02:00
|
|
|
/* Is */ /* A */ // A
|
2015-03-19 22:49:38 +01:00
|
|
|
// A
|
|
|
|
|
|
|
|
// Multiline
|
|
|
|
// Comment
|
|
|
|
|
|
|
|
test {}
|
|
|
|
|
|
|
|
// This
|
|
|
|
/* Is */
|
|
|
|
// A
|
|
|
|
// Trailing
|
|
|
|
|
|
|
|
// Multiline
|
|
|
|
// Comment
|
2016-07-13 01:03:08 +02:00
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
|
|
|
test // test
|
|
|
|
|
|
|
|
// test
|
|
|
|
{
|
|
|
|
}
|
|
|
|
`,
|
|
|
|
output: `
|
|
|
|
test { // test
|
|
|
|
// test
|
Implement list of maps
Allow property value to be a list of maps, e.g.
my_module {
my_list: [
{ name: "foo", value: 42, something: true, },
{ name: "bar", value: 34, something: false, },
],
}
Test: internal
Change-Id: I2fc37d692aac39f23c9aa7bda2859ab49f3bc672
2020-02-12 07:39:47 +01:00
|
|
|
}
|
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
|
|
|
// test
|
|
|
|
stuff {
|
|
|
|
namespace: "google",
|
|
|
|
string_vars: [
|
|
|
|
{
|
|
|
|
var: "one",
|
|
|
|
values: [ "one_a", "one_b",],
|
|
|
|
},
|
|
|
|
{
|
|
|
|
var: "two",
|
|
|
|
values: [ "two_a", "two_b", ],
|
|
|
|
},
|
|
|
|
],
|
|
|
|
}`,
|
|
|
|
output: `
|
|
|
|
// test
|
|
|
|
stuff {
|
|
|
|
namespace: "google",
|
|
|
|
string_vars: [
|
|
|
|
{
|
|
|
|
var: "one",
|
|
|
|
values: [
|
|
|
|
"one_a",
|
|
|
|
"one_b",
|
|
|
|
],
|
|
|
|
},
|
|
|
|
{
|
|
|
|
var: "two",
|
|
|
|
values: [
|
|
|
|
"two_a",
|
|
|
|
"two_b",
|
|
|
|
],
|
|
|
|
},
|
|
|
|
],
|
|
|
|
}
|
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
|
|
|
// test
|
|
|
|
stuff {
|
|
|
|
namespace: "google",
|
|
|
|
list_of_lists: [
|
|
|
|
[ "a", "b" ],
|
|
|
|
[ "c", "d" ],
|
|
|
|
],
|
|
|
|
}
|
|
|
|
`,
|
|
|
|
output: `
|
|
|
|
// test
|
|
|
|
stuff {
|
|
|
|
namespace: "google",
|
|
|
|
list_of_lists: [
|
|
|
|
[
|
|
|
|
"a",
|
|
|
|
"b",
|
|
|
|
],
|
|
|
|
[
|
|
|
|
"c",
|
|
|
|
"d",
|
|
|
|
],
|
|
|
|
],
|
2016-07-13 01:03:08 +02:00
|
|
|
}
|
2022-02-09 03:10:12 +01:00
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
|
|
|
// test
|
|
|
|
stuff {
|
|
|
|
namespace: "google",
|
|
|
|
list_of_structs: [{ key1: "a", key2: "b" }],
|
|
|
|
}
|
|
|
|
`,
|
|
|
|
output: `
|
|
|
|
// test
|
|
|
|
stuff {
|
|
|
|
namespace: "google",
|
|
|
|
list_of_structs: [
|
|
|
|
{
|
|
|
|
key1: "a",
|
|
|
|
key2: "b",
|
|
|
|
},
|
|
|
|
],
|
|
|
|
}
|
2023-05-17 03:46:33 +02:00
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
|
|
|
// test
|
|
|
|
foo {
|
|
|
|
stuff: [
|
|
|
|
"a", // great comment
|
|
|
|
"b",
|
|
|
|
],
|
|
|
|
}
|
|
|
|
`,
|
|
|
|
output: `
|
|
|
|
// test
|
|
|
|
foo {
|
|
|
|
stuff: [
|
|
|
|
"a", // great comment
|
|
|
|
"b",
|
|
|
|
],
|
|
|
|
}
|
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
|
|
|
// test
|
|
|
|
foo {
|
|
|
|
stuff: [
|
|
|
|
"a",
|
|
|
|
// b comment
|
|
|
|
"b",
|
|
|
|
],
|
|
|
|
}
|
|
|
|
`,
|
|
|
|
output: `
|
|
|
|
// test
|
|
|
|
foo {
|
|
|
|
stuff: [
|
|
|
|
"a",
|
|
|
|
// b comment
|
|
|
|
"b",
|
|
|
|
],
|
|
|
|
}
|
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
|
|
|
// test
|
|
|
|
foo {
|
|
|
|
stuff: [
|
|
|
|
"a", // a comment
|
|
|
|
// b comment
|
|
|
|
"b",
|
|
|
|
],
|
|
|
|
}
|
|
|
|
`,
|
|
|
|
output: `
|
|
|
|
// test
|
|
|
|
foo {
|
|
|
|
stuff: [
|
|
|
|
"a", // a comment
|
|
|
|
// b comment
|
|
|
|
"b",
|
|
|
|
],
|
|
|
|
}
|
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
input: `
|
|
|
|
// test
|
|
|
|
foo {
|
|
|
|
stuff: [
|
|
|
|
"a",
|
|
|
|
// b comment
|
|
|
|
// on multiline
|
|
|
|
"b",
|
|
|
|
],
|
|
|
|
}
|
|
|
|
`,
|
|
|
|
output: `
|
|
|
|
// test
|
|
|
|
foo {
|
|
|
|
stuff: [
|
|
|
|
"a",
|
|
|
|
// b comment
|
|
|
|
// on multiline
|
|
|
|
"b",
|
|
|
|
],
|
|
|
|
}
|
|
|
|
`,
|
|
|
|
},
|
|
|
|
{ // Line comment are treat as groups separator
|
|
|
|
input: `
|
|
|
|
// test
|
|
|
|
foo {
|
|
|
|
stuff: [
|
|
|
|
"b",
|
|
|
|
// a comment
|
|
|
|
"a",
|
|
|
|
],
|
|
|
|
}
|
|
|
|
`,
|
|
|
|
output: `
|
|
|
|
// test
|
|
|
|
foo {
|
|
|
|
stuff: [
|
|
|
|
"b",
|
|
|
|
// a comment
|
|
|
|
"a",
|
|
|
|
],
|
|
|
|
}
|
Select statements
Select statements are a new blueprint feature inspired by bazel's select
statements. They are essentially alternative syntax for soong config
variables that require less boilerplate. In addition, they support
making decisions based on a module's variant, which will eliminate
the need for manual property struct manipulation, such as the arch
mutator's arch: and target: properties.
In order to support decisions based on the variant, select statements
cannot be evaluated as soon as they're parsed. Instead, they must be
stored in the property struct unevaluated. This means that individual
properties need to change their type from say, string, to
Configurable[string]. Currently, only configurable strings, bools, and
string slices are supported, but more types can be added later.
The module implementation must call my_property.Evaluate(ctx) in order
to get the final, resolved value of the select statement.
Bug: 323382414
Test: go tests
Change-Id: I62f8721d7f0ac3d1df4a06d7eaa260a5aa7fcba3
2024-02-02 02:44:27 +01:00
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
name: "Basic selects",
|
|
|
|
input: `
|
|
|
|
// test
|
|
|
|
foo {
|
|
|
|
stuff: select(soong_config_variable("my_namespace", "my_variable"), {
|
|
|
|
"a": "a2",
|
|
|
|
// test2
|
|
|
|
"b": "b2",
|
|
|
|
// test3
|
|
|
|
_: "c2",
|
|
|
|
}),
|
|
|
|
}
|
|
|
|
`,
|
|
|
|
output: `
|
|
|
|
// test
|
|
|
|
foo {
|
|
|
|
stuff: select(soong_config_variable("my_namespace", "my_variable"), {
|
|
|
|
"a": "a2",
|
|
|
|
// test2
|
|
|
|
"b": "b2",
|
|
|
|
// test3
|
|
|
|
_: "c2",
|
|
|
|
}),
|
|
|
|
}
|
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
name: "Remove select with only default",
|
|
|
|
input: `
|
|
|
|
// test
|
|
|
|
foo {
|
|
|
|
stuff: select(soong_config_variable("my_namespace", "my_variable"), {
|
|
|
|
// test2
|
|
|
|
_: "c2",
|
|
|
|
}),
|
|
|
|
}
|
|
|
|
`,
|
|
|
|
output: `
|
|
|
|
// test
|
|
|
|
foo {
|
|
|
|
stuff: "c2", // test2
|
|
|
|
}
|
|
|
|
`,
|
|
|
|
},
|
|
|
|
{
|
|
|
|
name: "Appended selects",
|
|
|
|
input: `
|
|
|
|
// test
|
|
|
|
foo {
|
|
|
|
stuff: select(soong_config_variable("my_namespace", "my_variable"), {
|
|
|
|
"a": "a2",
|
|
|
|
// test2
|
|
|
|
"b": "b2",
|
|
|
|
// test3
|
|
|
|
_: "c2",
|
|
|
|
}) + select(release_variable("RELEASE_TEST"), {
|
|
|
|
"d": "d2",
|
|
|
|
"e": "e2",
|
|
|
|
_: "f2",
|
|
|
|
}),
|
|
|
|
}
|
|
|
|
`,
|
|
|
|
output: `
|
|
|
|
// test
|
|
|
|
foo {
|
|
|
|
stuff: select(soong_config_variable("my_namespace", "my_variable"), {
|
|
|
|
"a": "a2",
|
|
|
|
// test2
|
|
|
|
"b": "b2",
|
|
|
|
// test3
|
|
|
|
_: "c2",
|
|
|
|
}) + select(release_variable("RELEASE_TEST"), {
|
|
|
|
"d": "d2",
|
|
|
|
"e": "e2",
|
|
|
|
_: "f2",
|
|
|
|
}),
|
|
|
|
}
|
2015-01-09 04:35:10 +01:00
|
|
|
`,
|
|
|
|
},
|
|
|
|
}
|
|
|
|
|
|
|
|
func TestPrinter(t *testing.T) {
|
|
|
|
for _, testCase := range validPrinterTestCases {
|
Select statements
Select statements are a new blueprint feature inspired by bazel's select
statements. They are essentially alternative syntax for soong config
variables that require less boilerplate. In addition, they support
making decisions based on a module's variant, which will eliminate
the need for manual property struct manipulation, such as the arch
mutator's arch: and target: properties.
In order to support decisions based on the variant, select statements
cannot be evaluated as soon as they're parsed. Instead, they must be
stored in the property struct unevaluated. This means that individual
properties need to change their type from say, string, to
Configurable[string]. Currently, only configurable strings, bools, and
string slices are supported, but more types can be added later.
The module implementation must call my_property.Evaluate(ctx) in order
to get the final, resolved value of the select statement.
Bug: 323382414
Test: go tests
Change-Id: I62f8721d7f0ac3d1df4a06d7eaa260a5aa7fcba3
2024-02-02 02:44:27 +01:00
|
|
|
t.Run(testCase.name, func(t *testing.T) {
|
|
|
|
in := testCase.input[1:]
|
|
|
|
expected := testCase.output[1:]
|
|
|
|
|
|
|
|
r := bytes.NewBufferString(in)
|
|
|
|
file, errs := Parse("", r, NewScope(nil))
|
|
|
|
if len(errs) != 0 {
|
|
|
|
t.Errorf("test case: %s", in)
|
|
|
|
t.Errorf("unexpected errors:")
|
|
|
|
for _, err := range errs {
|
|
|
|
t.Errorf(" %s", err)
|
|
|
|
}
|
|
|
|
t.FailNow()
|
2015-01-09 04:35:10 +01:00
|
|
|
}
|
|
|
|
|
Select statements
Select statements are a new blueprint feature inspired by bazel's select
statements. They are essentially alternative syntax for soong config
variables that require less boilerplate. In addition, they support
making decisions based on a module's variant, which will eliminate
the need for manual property struct manipulation, such as the arch
mutator's arch: and target: properties.
In order to support decisions based on the variant, select statements
cannot be evaluated as soon as they're parsed. Instead, they must be
stored in the property struct unevaluated. This means that individual
properties need to change their type from say, string, to
Configurable[string]. Currently, only configurable strings, bools, and
string slices are supported, but more types can be added later.
The module implementation must call my_property.Evaluate(ctx) in order
to get the final, resolved value of the select statement.
Bug: 323382414
Test: go tests
Change-Id: I62f8721d7f0ac3d1df4a06d7eaa260a5aa7fcba3
2024-02-02 02:44:27 +01:00
|
|
|
SortLists(file)
|
2015-01-09 04:35:10 +01:00
|
|
|
|
Select statements
Select statements are a new blueprint feature inspired by bazel's select
statements. They are essentially alternative syntax for soong config
variables that require less boilerplate. In addition, they support
making decisions based on a module's variant, which will eliminate
the need for manual property struct manipulation, such as the arch
mutator's arch: and target: properties.
In order to support decisions based on the variant, select statements
cannot be evaluated as soon as they're parsed. Instead, they must be
stored in the property struct unevaluated. This means that individual
properties need to change their type from say, string, to
Configurable[string]. Currently, only configurable strings, bools, and
string slices are supported, but more types can be added later.
The module implementation must call my_property.Evaluate(ctx) in order
to get the final, resolved value of the select statement.
Bug: 323382414
Test: go tests
Change-Id: I62f8721d7f0ac3d1df4a06d7eaa260a5aa7fcba3
2024-02-02 02:44:27 +01:00
|
|
|
got, err := Print(file)
|
|
|
|
if err != nil {
|
|
|
|
t.Errorf("test case: %s", in)
|
|
|
|
t.Errorf("unexpected error: %s", err)
|
|
|
|
t.FailNow()
|
|
|
|
}
|
2015-01-09 04:35:10 +01:00
|
|
|
|
Select statements
Select statements are a new blueprint feature inspired by bazel's select
statements. They are essentially alternative syntax for soong config
variables that require less boilerplate. In addition, they support
making decisions based on a module's variant, which will eliminate
the need for manual property struct manipulation, such as the arch
mutator's arch: and target: properties.
In order to support decisions based on the variant, select statements
cannot be evaluated as soon as they're parsed. Instead, they must be
stored in the property struct unevaluated. This means that individual
properties need to change their type from say, string, to
Configurable[string]. Currently, only configurable strings, bools, and
string slices are supported, but more types can be added later.
The module implementation must call my_property.Evaluate(ctx) in order
to get the final, resolved value of the select statement.
Bug: 323382414
Test: go tests
Change-Id: I62f8721d7f0ac3d1df4a06d7eaa260a5aa7fcba3
2024-02-02 02:44:27 +01:00
|
|
|
if string(got) != expected {
|
|
|
|
t.Errorf("test case: %s", in)
|
|
|
|
t.Errorf(" expected: %s", expected)
|
|
|
|
t.Errorf(" got: %s", string(got))
|
|
|
|
}
|
|
|
|
})
|
2015-01-09 04:35:10 +01:00
|
|
|
}
|
|
|
|
}
|