Closed
Description
#[cfg(feature = "validation")]
[debug_utils_ext, (*surface_extensions).to_owned()].concat()
#[cfg(not(feature = "validation"))]
surface_extensions.to_owned()
Error code:
error: expected `;`, found `#`
--> src\engine\renderer\context\instance.rs:44:73
|
44 | [debug_utils_ext, (*surface_extensions).to_owned()].concat()
| ^ help: add `;` here
45 |
46 | #[cfg(not(feature = "validation"))]
| - unexpected token
Metadata:
rustc 1.67.0-nightly (e1d819583 2022-12-05)
binary: rustc
commit-hash: e1d819583f0bf13b016b119c1c2c43e6d3979450
commit-date: 2022-12-05
host: x86_64-pc-windows-msvc
release: 1.67.0-nightly
LLVM version: 15.0.4
Activity
[-]Unexpected token: `expected `;`, found `#`.[/-][+]Unexpected token: expected `;`, found `#`.[/+]compiler-errors commentedon Dec 21, 2022
What is the issue you are reporting here @Jerrody ?
Jerrody commentedon Dec 21, 2022
Well, I thought that compiler can understand that
#[cfg()]
is related to the block of code, but it fails.Noratrieb commentedon Dec 22, 2022
Can you post a minimal reproducible example that demonstrates your issue? Or at least mention exactly what you'd expect to happen and why.
Even code that is cfged out is still required to parse successfully.
Jerrody commentedon Dec 22, 2022
Let's show you what exactly problem I have.
Full code:
And I get this error:
SkiFire13 commentedon Dec 22, 2022
You seem to already have posted this in this discussion in the internals forum a month ago. What you're asking seems a rather big change to me, I'm not that familiar with how the compiler parser works but I believe it currently requires your program syntax to be correct before
#[cfg(...)]
macros are expanded, which is not true for your example, so some fundamental changes would be needed.Jerrody commentedon Dec 22, 2022
Oh, damn, sorry. I totally forgot that I made a post.
Well, if it's not a bug and parser works like this it is bad, anyway, exists alternative way to write like this.
But for me my issue is a candidate to feature request or a bug. Anyway, I'm not a lang dev, so I don't know what scales of this defect (?).
lukas-code commentedon Dec 22, 2022
The workaround for this is to wrap the expressions in a block:
Jerrody commentedon Dec 22, 2022
I solved this issue exactly as you did.
albertlarsan68 commentedon Dec 23, 2022
Another way to do this is using the
cfg!
macro andif ... else
.I personally thinks it is more clear, and should optimize the same.
Jerrody commentedon Dec 24, 2022
Work is not the same, due to
cfg!
compile-time evaluating an expression that we pass in it and evaluates only it, but at the same time everything compiles what is inside ofif else
.6 remaining items