Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#if and #ifdef fail to parse #64

Open
arturoc opened this issue Apr 20, 2019 · 13 comments
Open

#if and #ifdef fail to parse #64

arturoc opened this issue Apr 20, 2019 · 13 comments

Comments

@arturoc
Copy link

arturoc commented Apr 20, 2019

Any input with #if or #ifdef fails to parse with an error of ErrorKind Custom(0).

eg:

use glsl::parser::{Parse, ParseResult};
use glsl::syntax::TranslationUnit;

fn main() {
    let fs = "#define USE_GLOBAL_COLOR  1

            uniform vec4 color;
            out vec4 out_color;

            void main() {
                #if USE_GLOBAL_COLOR
                    out_color = color;
                #else
                    out_color = vec4(1., 0., 0., 1.);
                #endif
            }";

    let parsed = match TranslationUnit::parse_str(fs){
        ParseResult::Ok(parsed) => parsed,
        ParseResult::Incomplete(_needed) =>
            panic!("More data needed to parse shader"),
        ParseResult::Err(err) =>
            panic!("Error parsing shader: {}", err)
    };
}

panics with error Custom(0). removing the ifs makes the parser work correctly

@hadronized
Copy link
Owner

Yes, CPP is not yet supported. Only a very few subset of it is currently supported. I don’t really know whether glsl should support it, or if it should be done via a CPP crate.

@hadronized
Copy link
Owner

I’m going to work on this. I will likely provide a new feature for parsing with options.

@arturoc
Copy link
Author

arturoc commented Jul 19, 2019

that would be great thanks!

@jrmuizel
Copy link
Contributor

Do you have a rough idea how you want to implement preprocessing? It seems difficult to fit into the current parser which doesn't seem to have a separate lexing stage.

@hadronized
Copy link
Owner

Yes it doesn’t. At first I thought to use a different crate for this, because the CPP used is exactly the same as the C one, plus some specific pragma for GLSL.

@jrmuizel
Copy link
Contributor

Using an existing cpp preprocessing crate will need some modification as the GLSL preprocessor allows white space before '#'. There might be other differences as well.

@hadronized
Copy link
Owner

See #95.

@hadronized
Copy link
Owner

#96 is going to bring those to the next release. :)

@arturoc
Copy link
Author

arturoc commented Nov 12, 2019

that's great, haven't had a chance to test it yet but will report as soon as i do if i find any problem. should i close this issue?

thanks for looking into it!

@hadronized
Copy link
Owner

Nah leave it open, we’ll close it whenever we have more test data and usage. You’re very welcome.

@hadronized
Copy link
Owner

Feel free to tell me whenever you have time if your issue is fixed with glsl-3.0. 🙂

@Strum355
Copy link

Strum355 commented Jan 7, 2020

using v4.0.0

[dependencies]
glsl = "4.0.0"

the following fails to parse

void make_drawbuffer() {
    #ifdef GL_RENDERER_GEFORCE
        vec3 temp   = clamp(scenecol, 1.0/65530.0, 65535.0);   //NaN fix on nvidia
    #else
        vec3 temp   = clamp(scenecol, 0.0, 65535.0);
    #endif
}

with error:

    #ifdef GL_RENDERER_GEFORCE
    ^
expected '}', found #

@hadronized
Copy link
Owner

Yes, unfortunately, those are currently only supported at the top-level of your shader.

unjello added a commit to unjello/glsl that referenced this issue Jul 12, 2021
unjello added a commit to unjello/glsl that referenced this issue Jul 12, 2021
unjello added a commit to unjello/glsl that referenced this issue Jul 12, 2021
unjello added a commit to unjello/glsl that referenced this issue Jul 12, 2021
unjello added a commit to unjello/glsl that referenced this issue Jul 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants