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
Parse Error Search Results empty #2915
Comments
Would it be possible for you to share the macro that produces the parse error so we can see if we can reproduce either issue? |
sorry, I wish I could. it's got a lot of private details baked in that my company wouldn't be happy if I shared. could I provide some stats on it? is there particular code or structures that are known to cause errors? |
@connerk are you using vbWatchDog? There's a known issue with processing member attributes of vbWatchdog's generated code. Other than that.. Do you have logging enabled? The logs would have exception details that could be useful. |
not using vbWatchDog. I do use MZ-Tools but even if I unload it Rubberduck still gives me a parsing error. I've just created a macro with one module, containing Rubberduck did not give me a parse error. I have not turned on logging. I see it in the settings and will see what I can get from it. |
I suspect an IOException (or something derived from it) in the preprocessing stage - logs can get very verbose at TRACE level, but they also tell us the most about the sequence of events. We use NLog for logging, it handles all the archiving automatically, and we set it up to clear the current log everytime RD starts, which works well for diagnosing issues. |
ok! Here are logs from when I click the refresh button in the ribbon. actual application: simple 1 module with addTwoNumbers() function |
The first log is relevant to the parse error and point to line 746, column 23 of module "AppVariables". It looks like it's failing on some sort of declaration. Are there a couple lines around there that can be shared? If not, how about the same syntax with only the variable names \ literal values changed? The second log is a bit more puzzling - from that one it looks like we tried to load a library from a referenced project or library, but couldn't load it because the typelib wasn't registered. I'm not exactly sure how that's possible if VBA is able to open and compile it. Do you reference anything that isn't a library? For example, an .xlam file? |
Here is the whole thing with the lines in tact, redacted where necessary. if is RD looking at the first line as "Attribute VB_Name = "AppVariables"" then line 746 is this doesn't explain what is causing the error in the addTwoNumbers() project though.. |
If I had to guess, I'd guess the grammar thinks that |
@Hosch250 sorry, I don't think that's it. That's a static array declaration not a method. there are 33 of them in this module |
@connerk - We've had issues with the potential ambiguity in the VBA grammar between array subscripts and procedure argument lists. I'm pretty sure it's some combination of multi-dimensional fixed array, Thanks for providing the file - that helps tremendously. |
I pasted that entire file into Excel, and everything works as expected. |
just saw these questions: Referring to the actual project: if I open a brand new book (no modules): the same above but with late bound unit test => success |
Huh wtf
Looks like we need the COM collector to skip anything it can't load - whatever the reason is. |
should I re-install maybe? is it System.Runtime.InteropServices.COMException that is not registered? |
Nah, I don't think it would fix anything - looks like Rubberduck doesn't like loading its own type library at runtime; we have a plan to use actual .net reflection to pull the COM-visible declarations from |
A reinstall probably won't help, although we've also run into a couple instances where RD has difficulty loading its own typelib with a |
@connerk hmm this looks like a bug in the declaration finder (well in the FWIW I pasted Compare to: From: Sub DoSomething()
Dim foo()
End Sub When a variable is recognized as an array, the commandbar text for it includes |
if I put AppVariables into a fresh workbook I also don't get a parse error. |
The double space shouldn't matter, our grammar is (mostly) written against the VBA language specifications, not against what the VBE turns processed code into (although we do have a few hacks that rely on it). I'm positively confused now. private void AddImplementedInterface(Declaration potentialClassModule)
{
if (potentialClassModule.DeclarationType != DeclarationType.ClassModule)
{
return; // this guard clause SHOULD prevent the InvalidCastException you're seeing
}
var classModule = (ClassModuleDeclaration)potentialClassModule;
foreach (var implementedInterfaceName in classModule.SupertypeNames)
{
var expressionContext = _expressionParser.Parse(implementedInterfaceName);
var implementedInterface = _bindingService.ResolveType(potentialClassModule, potentialClassModule, expressionContext);
if (implementedInterface.Classification != ExpressionClassification.ResolutionFailed)
{
classModule.AddSupertype(implementedInterface.ReferencedDeclaration);
((ClassModuleDeclaration)implementedInterface.ReferencedDeclaration).AddSubtype(classModule); // << line 55
}
else
{
Logger.Warn("Failed to resolve interface {0}.", implementedInterfaceName);
}
}
} |
Looking again, it looks like we're making an assumption here, that var implementedInterface = _bindingService.ResolveType(potentialClassModule, potentialClassModule, expressionContext); We need to look at |
@connerk Can you tell us the names of the interfaces/classes your classes and forms implement? That might help a lot to understand what is going wrong here. |
sorry, I'm lost on the terminology there.. when I make a completely empty workbook, add a RD test module with early binding, the error occurs. no COM or Excel add-ins other than RD are active. (to my awareness!) https://www.dropbox.com/s/ci0cxhtwajprfbo/RubberDuck%20Parsing%20Error%20Workbook_Simple.xlsm?dl=0 Log File: |
I think we have multiple issues combined in this one. I was looking into the issue in your last log file, the one with the error in the Does this error occur in the empty workbook with only the test module or is there another error in the log in that case? |
Log File: That's not a directory on my workstation! |
That's the path on the machine RD was built on. |
I assumed that. so it's ok that it's in my log file? it's not referring to a file location it's looking for? |
There is nothing in the log file at present even though it is set to debug level. |
UPDATE:
Hang on. Now with similar test as i closed Excel and re-opened i have:
I would really like to be able to ensure reference library loads. Additional side-point is that when reference was loading it had to be unchecked for the test to be found when clicking the refresh in test explorer. When the test ran it added itself back in. But, currently not appearing at all even when opening Excel anew. |
Should i post this elsewhere as it currently seems to be an issue with loading the RubberDuck reference into references? Is so, is there an appropriate place you could suggest please? I have added the reference in by browsing to the file: Rubberduck.tlb However, now the parse error immediately appears again irrespective of anything else being present. Add reference = get parse error. |
@quentinharris nah it's fine, that's a known problem - for some reason loading Rubberduck.tlb with Rubberduck.dll to iterate the exposed COM types causes the COM declaration collector to blow up. We're planning on skipping the loading of that particular library and getting the declarations through .net reflection instead, so that the parser won't try to load Rubberduck.tlb at all and still know about the exposed COM types. The interim solution is unfortunately to stick to late-binding with Rubberduck.tlb, whenever that problem happens. |
Ok. Many thanks. Is this an allocated development item that i can track? |
I'm having the same problem. The ducks just spin and spin. I updated to the latest version of Rubberduck which may have been a mistake. Currently parsing my code doesn't work at all. I'm not sure what it's hanging on. This is from my logs:
|
@alexkadis Do you mean version 2.1.2.2850-pre when you say "Latest"? Could you try opening all modules in the VBE and reparse? See also #3753 |
Note that while I wrote this message, The release 2.1.2.2851-pre was finished :) |
@Vogel612 looks like @alexkadis downloaded .2849 just as I was merging .2850 (the CI build for .2851 completed just now); .2849 was the PR reinstating content hash computation on the QMN's, .2850 was the weak-reference COM safe PR, and .2851 fixes the SLL parser mode for array declarations with extraneous whitespace. |
@Vogel612 I have v2.1.2.2849-pre. I can install .2851 if that's helpful. Here's the logs after opening up all of the code:
|
@alexkadis thanks! make sure you uninstall the previous build through control panel's add/remove programs first 😄 .2851 addresses an edge case that hindered parser performance, but .2850 has implications that may affect this issue (one way or another). Let us know how it goes! @rubberduck-vba/dev from the stack trace, it looks like it blew up trying to determine the base/super type for a document module - this is something @WaynePhillipsEA's API can address. |
@retailcoder I uninstalled using add/remove programs and installed .2854 (latest as of this comment). I decided to change the log-level to debug and some more interesting information showed up. It seems the The full RubberduckLog.txt I don't want to bother posting all of my code (kinda useless without the database and I can't share that), but here's a snippet: Module:
The relevant code:
Also worth noting that the biggest things I changed before all of this started happening:
|
@alexkadis This isn't relevant to the bug report but I would point out that there is a workaround -- use I am aware there are several code samples where they might suggest using a bang operator to get a member from the collection but I personally think it should be avoided because it's more likely to hide potential compile-time errors, and turn those into a run-time errors, which only increase the debugging effort. Mind you, Rubberduck will need to get smart with that kind of syntax, so it should be fixed eventually. But if you don't want to wait for it, the workaround suggested can help you out. |
@bclothier Thanks! Didn't know that, I've made some updates to my code, and I'm guessing that the remaining errors are relevant. |
This was already reported in this issue: #3753, and there has been already a PR that should have fixed it. Can you make sure you've updated the version of Rubberduck? I see that you are using 2.1.2.2854 - which already includes this PR. So apparently this didn't fix the issue completely. |
@bclothier Yup, using 2.1.2.2854. Are the two issues related or just a coincidence that I'm experiencing both? #3753 is in the logs, but in the UI, rubberduck hanging on "Parse Error" (this issue) |
AIUI, they are same error, just a slightly different symptoms. |
@alexkadis Regarding the DEBUG entry in your Rubberduck log, this does not mean that we could not parse the code; only the SLL mode failed and we retried using LL. Since the remaining entries you have posted do not contain a corresponding ERROR level log, the LL parsre succeeded. Let me provide a bit of background here. We use two diffferent parsing strategies, the fast but restricted SLL strategy and the powerful but slower LL strategy. The two most important differences between the two are that the SLL parser cannot revert any decision about what a subrule matches and that the subrules are matched without context. This can make subrules match too much or let it take the wrong of two alternatives possible on first sight. Then it errors out. The LL strategy will basically revert its decisions and come to the correct conclusion, which is identical to the SLL one if the SLL strategy succeeds. So, our approach is to first try SLL mode, which works almost always, and fall back to LL mode if it did not work. This is also the reason why the SLL error is only DEBUG level, but the LL error is ERROR level. Regarding the remaining warnings, it seems that Rubberduck has not been able to identify some constants and types from referenced libraries, which we will have to look into. This is basically the problem from your issue #3762. The final ERROR log entry is what makes your parse fail. Whenever we encounter an unexpeted exception wile parsing, we set the ParserError state to deactivate most features; Rubberduck is not in a usable state is that happens. The specific error encountered here is indeed the same as in #3753, which is a painful issue with the VBE's own API. However, this particular point should be fixed once PR #3778 gets merged. |
Ignore the earlier version of my comment. While .2869 didn't resolve the issue, .2870 did! Thank you all |
@alexkadis just to clarify - the PR 3778 actually got merged into .2870 which was why .2869 didn' t work. Glad to get confirmation it did! |
@bclothier perhaps I spoke too soon... When opening Access for the first time, no error. But if I run Compact & Repair, the error is back:
|
That is a separate issue. Can you please open a new issue? |
I have a functioning Excel macro that always produces a Rubberduck parse Error.
When I click the icon to view the parse errors, the search results box is empty
Version 2.0.13.32288
The text was updated successfully, but these errors were encountered: