Built-in methods, variables and structs support

[Darkyenus]

There are already unused files for this in resources/environment.

[Darkyenus]

We should probably solve glsl versions first. Probably most intuitive would be to:

• Create a structure of environment files, sorted by glsl version and purpose (vertex/fragment/...)
• Check all files by default, unless #version directive is present. If it is, check all as well, but warn when using features unavailable in current version.

Using this philosophy, extensions could be handled as well.

However, this will create a lot of redundancy, because most of the functions stay the same between versions. Alternatives would be:

• Have only delta changes in all but first version
• Annotate (somehow) all functions/variables with their relation to glsl versions

Question also is, how to recognize and account for GLES shaders in this system.

[AbigailBuccaneer]

I've added more files to this in the environment branch. I think once we have better preprocessing it makes more sense to just use one file with preprocessor directives to handle this. Alternatively, if we supported annotations (eg. GCC-like __attribute__((version(410)) or via #pragma somethingorother) that'd then give an easy way of specifying them all in one file and having information about the functions not in the current version.

GLES SL versions are 100, 300 and 310, which conveniently have never been used for GLSL versions (which started at 110 and skipped from 150 to 330). This may not always be the case, but Khronos will have to think about it as much as we will. Of course, this does mean that you can't assume that the version numbers form a single monotonic line, as I have done in the environment branch.

[AbigailBuccaneer]

(See #40 which is a prerequisite for this.)

[Darkyenus]

I'd like to keep the ability to recognise the function even if doesn't exist in the current version, but I think that the preprocessor support would have to be very advanced to be able to do that reliably. I don't know, maybe it will be easier then it seems, but so far I'm in favor of annotating somehow. Since these annotations will be supported only in environment files, we can make up our own syntax that is readable and comfortable.

Making the tag up isn't trivial though, but if we assume that GLES versions will be always different to GL versions, something like <110,120,300> float cos(float x); (for denoting that cos is available in GL 110, 120 and GLES 300 (only those versions)) might be enough. Something like <versions>{ function1; function2; ...} might help with resulting verbosity and still be easy to parse. (Maybe even easier)

[AbigailBuccaneer]

C++11 attributes ([[version(110, 300)]]) might be nice - they look clean and minimal like your angle-bracket suggestion, but are also supported as standard in other languages (ie. C++11) so there's some precedence for it. Double opening square brackets aren't currently valid anywhere in the language, but you can make something that's syntactically well-formed with something like 100<110,120,300>330.

Supporting attributes for things other than versions would be hypothetically useful for adding other annotations to the standard library - possibly something like [[minimum(8)]] for the implementation-defined limits that are defined in the shader environment?

[AbigailBuccaneer]

It can also be used for error highlighting based on expression analysis, as well as feeding more info back into the analysis:

float [[contract(x >= 0 && sqrt(x) >= 0)]] sqrt(float x);

[Fox32]

First, very nice plugin!

Does this issue include the missing deduction of return values for build-in functions, or should I create a new one?
For example:

float unpackFloat(vec4 v) {
  return dot(v, vec4(1.0, 1.0 / 255.0, 1.0 / 65025.0, 1.0 / 160581375.0));
}

It is able to deduce the types of the arguments to dot but unable to deduce it's return type and shows a warning.

[Darkyenus]

@Fox32 Thanks!

It does, support for methods here means that the plugin will know which methods there are, what arguments do they take and what type they return.

More thoughts on the issue:
What if the importing wasn't done by annotated source file, but through something directly in Java? There could be an object which would allow specifying and searching for methods/etc., let's call it FunctionRepository which would allow doing something like this:

class GLSLFunctionRepository extends FunctionRepository {
    //function(name, returnType, argTypes...);
    function("sin", GEN_TYPE, GEN_TYPE);
    function("cos", GEN_TYPE, GEN_TYPE);
    function("doMagic", FLOAT, GEN_TYPE, GEN_TYPE).since(130).sinceES(150);
    ...
}

FunctionRepository fr;
FunctionType ft = fr.findFunction("doMagic", VEC2, VEC2);
ft.returnType == FLOAT

Similar "Repository" for variables and types or it could be integrated into one.

I am seriously considering this, because it will be less work, faster, more flexible, predictable, and we will have tools to deal with it (refactoring java is easier than glsl with custom annotations).

[AbigailBuccaneer]

Having had a further look at how function lookups and parameter info is handled, I suspect building the function list in Java would be easier. (Specifically, a ResolveResult can be either a PsiElementResolveResult or a custom implementation that can be used to resolve to built-in functions.)

[wyozi]

In my game engine I support importing shaders using #pragma import filename. I've been thinking of a way to allow plugin user to specify what kind of syntax their imports use and then add support for file imports to glsl4idea. Haven't had any good ideas about that yet but the same concept could be used for built in functions.

The built-in functions are conveniently stored in files as is, so if built-in function loading was implemented by implicitly (without explicit annotations or directives) importing the resource files, it would solve a few problems:

• User shader code would directly benefit from changes to built-in function documentation parsing code and vice versa (code to fetch documentation for function would only have to be implemented once!)
• If the user shader glsl file specifies glsl version with #version and the builtin functions are loaded after this, only the correct functions would remain without any additional processing needed (this needs Version and stage should be parsed/inferred #40)
• It would be trivial to implement custom shader import directives later

While Java function repository idea would definitely be faster, I think it would also be less flexible. I will maybe look more into the idea later.

Also sorry about messy text flow, it's late.

[darkoffalex]

Hello. Thanks for plugin. What is the status of the issue now? When can we expect this enhancement to be implemented?

[Darkyenus]

I don't currently have much time to work on my OSS, so don't expect this to be done anytime soon.