« first day (1927 days earlier)      last day (38 days later) » 

12:00 AM
[rubberduck-vba/Rubberduck] 1 issue comment.
[Minesweeper] New Users: 5, Games Played: 47, Bombs Used: 21, Moves Performed: 6906
2 hours later…
2:24 AM
> This will help those like myself that struggle with concepts. Seeing a live example like this is game changing for me.
3:01 AM
> So are we then in regards to documenting error numbers with inspections/codebase be more discoverable in search engines (google, bing, DuckDuckGo, etc) irrespective of their ranking?
@Duga hm, didn't think of SEO at all (again lol), but good point -- especially considering the inspection details pages on the website
3 hours later…
5:47 AM
> @MDoerner How does this look?

6 hours later…
11:29 AM
@MathieuGuindon @Duga It is error 91 if the object is Nothing and error 438, otherwise.
From the perspective of a compiler these errors are completely reasonable, but they are rubbish in comunicating the problem to the programmer.
2 hours later…
1:47 PM
[rubberduck-vba/Rubberduck] retailcoder pushed 15 commits to next (only showing some of them below)
[rubberduck-vba/Rubberduck] MDoerner pushed commit 7415d641 to next: Set up infrastructure to store failed procedure coercions
[rubberduck-vba/Rubberduck] MDoerner pushed commit 5a733e98 to next: Store failed procedure coercions for non-parameterized call statements
Introduce ProcedureRequiredInspection

This inspection reports all places in which an unparameterized procedure call is required but an object variable has been provided.
[rubberduck-vba/Rubberduck] MDoerner pushed commit 82c8b0da to next: Extract separate failed/unpund resolution collections on ModuleState into IFailedResolutionStore
[rubberduck-vba/Rubberduck] MDoerner pushed commit 14f957be to next: Set up infrastructure to store failed indexed default member accesses
Collect failed indexed default member resolutions

This also fixes various small bugs in the reference resolver. Moreover, now we actually check whether the number or arguments provided fits for index expressions.
Add DefaultMemberRequiredInspection

This inspection finds all failed indexed default member resolutions. The non-indexed ones are already covered by the ValueRequiredInspection and the ProcedureRequiredInspection.
[rubberduck-vba/Rubberduck] MDoerner pushed commit f02dd6a1 to next: Do not Let coerce on Property Let regardless of type
Added error numbers for runtime errors in info for failed default member reolution inspections

Also corrects the info for ObjectVariableNotSet: it is not always error 91, only if the variable is Nothing
Merge pull request #5146 from MDoerner/FailedLetCoercionOnObjectInspection

New Inspections for failed default member resolutions
[rubberduck-vba/Rubberduck] build for commit 38c928e5 on next: AppVeyor build succeeded
4 hours later…
1 hour later…
7:42 PM
@IvenBach I now want to find language-tans ... good job :)
8:22 PM
> **Rubberduck version information**
The info below can be copy-paste-completed from the first lines of Rubberduck's log or the About box:

OS: Microsoft Windows NT 10.0.18362.0, x64
Host Product: Microsoft Office x64
Host Version: 16.0.12026.20108
Host Executable: WINWORD.EXE

Looks like I'm getting a flase defalut member requirement for the function call StringifyArray. Its the line where I've allowed Ruberduck to insert the ignore annotation.
8:35 PM
@Duga I can patch up the resolver to not produce a failed Let coersion in this particular case, but the general problem is a bit problematic.
> Thanks for reporting this.

This is a problem with the resolver. Currently, the resolution of index expressions does not consider the case of a recursive call. Instead, it allways considers references to the function name as references to the variable holding the return value. This has to be changed.

The inspection itself reports the correct issues based on what the resolver provides.
9:09 PM
Ok, apparently, a recursive call always beats a default member call on the assigned return value.
10:08 PM
@M.Doerner does the resolver currently know about recursive calls? #3140 could be implementable if that knowledge was accessible to inspections.. hm, and we could have a hint-level RecursiveCallInspection just to flag them as such.
The resolver currently has no idea about recursive calls.
it's not really relevant for anything other than specific cases like this :)
it's good trivia to bring up to the user though
10:46 PM
> Closes #5147

This PR fixes that both the `IndexDefaultBinding` and the `ProcdureCoercionBinding` did not consider recursive function calls. For these, the expression referring to the function is classified as a variable becasue that is appropriate for the variable holding the return value. So, this situation needs to be special cased.
10:58 PM
[rubberduck-vba/Rubberduck] build for commit 7f63d650 on unknown branch: AppVeyor build succeeded
11:09 PM
[rubberduck-vba/Rubberduck] MDoerner pushed commit 0e37374f to next: Fix second parameter in format string for results of DefaultMemberRequiredInspection
Fix resolver around recursive function calls

This fixes that the reference to the contained function was treated like a variable instead of a function call.
Merge pull request #5148 from MDoerner/FixesAroundRecursiveFunctionCalls

Fixes around recursive function calls

« first day (1927 days earlier)      last day (38 days later) »