Note: This website is archived. For up-to-date information about D projects and development, please visit wiki.dlang.org.

Ticket #136 (new defect)

Opened 10 years ago

Last modified 10 years ago

Semantic highlighting fails in specific circumstances

Reported by: fvbommel Assigned to:
Priority: major Component: descent.astview
Version: 0.5 Keywords:
Cc:

Description

Semantic highlighting doesn't work in the nested function below: (Note the renamed llvm import and Format() call. Un-renaming the import or commenting out the Format call unbreaks semantic highlighting...)

module nestedfunc;

import tango.text.convert.Format;

// To get the code for this import:
// $ svn co http://svn.dsource.org/projects/llvmdc/binding/llvm/llvm
import llvm = llvm.llvm;            // must be renamed import

llvm.Value zero() { return null; }

void foo(llvm.Value rhs) {
    // Commenting out this line fixes highlighting for the nested function:
    auto blaat = Format("blaat: {}", rhs);
    
    // Only the signature works with "mark occurrences". Nothing in the body is
    // highlighted or marked.
    // (I don't know if the 'i' works, since there's nothing to link it to outside the body)
    void nested(size_t i) {
        llvm.Value[2] indices;
        indices[0] = zero;
        indices[1] = llvm.ConstantInt.GetU(llvm.Type.Int32, i);
    }
}

// same code as foo.nested, but this is highlighted, and
// "mark occurrences" links "zero" to the definition above
// (but not the use in foo.nested)
// Mark occurrences also works on "indices" where it doesn't
// in foo.nested.
void bar(size_t i) {
    llvm.Value[2] indices;
    indices[0] = zero;
    indices[1] = llvm.ConstantInt.GetU(llvm.Type.Int32, i);
}

Change History

11/16/08 22:14:22 changed by asterite

It works for me. But I won't close it until you give me the ok. First of all, where are you pointing the include path to llvm? You should point it to a directory that contains a folder named llvm. Like:

  • C:\
    • some_folder
      • llvm <-- point the include path here
        • llvm
          • c
            • Analysis.d
            • etc.
          • builder.d
          • etc.

Do you have it like that? Maybe that's the problem. (even though I pointed it to the second llvm and it worked anyway...)

11/16/08 22:37:08 changed by asterite

Or... maybe I fixed it in 0.5.3.20081116, I didn't realize half a month passed since the last nightly build. I probably fixed that because it has to do with inner functions and delegate bodies. Can you check this?