RELOAD!

[rubberduck-vba/Rubberduck] 1 opened issue. 3 issue comments.

[Minesweeper] Games Played: 99, Bombs Used: 46, Moves Performed: 14704, New Users: 5

Made it to github.com/rubberduck-vba/Rubberduck/blob/next/… so far.

On returning from that method codePaneTokenStream has the correct the correct tokens.

By that I mean there isn't any explicit Public (space after keyword accessor intentional) added to it.

No comments or annotations.

Coming up out of call stack it's returning the ModuleParseResults...

github.com/rubberduck-vba/Rubberduck/blob/next/… has a typo where it's missing the S in ModuleParSeResults.

[rubberduck-vba/Rubberduck] BZngr added label up-for-grabs to issue #5644: ImplicitVariantTypeInDeclarationList Inspection

[rubberduck-vba/Rubberduck] BZngr added label enhancement to issue #5644: ImplicitVariantTypeInDeclarationList Inspection

[rubberduck-vba/Rubberduck] BZngr opened issue #5644: ImplicitVariantTypeInDeclarationList Inspection

[rubberduck-vba/Rubberduck] BZngr added label feature-inspections to issue #5644: ImplicitVariantTypeInDeclarationList Inspection

[rubberduck-vba/Rubberduck] IvenBach created comment on issue #5644: ImplicitVariantTypeInDeclarationList Inspection

@IvenBach another typo in parSer

That concludes by saving all the states of the tokens for the parsed module.

[rubberduck-vba/Rubberduck] BZngr created comment on issue #5644: ImplicitVariantTypeInDeclarationList Inspection

> That's usually my preference - though I suspect that the owner/author of the original list would usually want to keep it as a list. Perhaps there could/should be two quickfixes available: MakeImplicitListDeclarationTypesExplicitAsList and MakeImplicitListDeclarationTypesExplicitAsOnePerLine. These would both call a single RefactoringAction with the requested option flagged in the RefactoringAction's model.

@IvenBach Typo in remeining.

Yet when the mock parser for the test returns and I look at parser it has the type accessibility as Public.

The comprehension disconnect I'm having is _parsingStageService.Parsemodules(toParse, token).

Within that member _parseRunner.ParseModules(modulesToParse, token) in invoked and the state is saved.

The state of each module is saved but it isn't accessible externally.

At least not until several steps back down the call stack back to where tho mock parser is ultimately populating a parser variable.

At that point parser.State.AllUserDeclarations which contains the UDT considers it to have Accessibility.Public.

You have any clue Mug?

[rubberduck-vba/Rubberduck] retailcoder created comment on issue #5644: ImplicitVariantTypeInDeclarationList Inspection

> Would this not be already covered by VariableTypeNotDeclared?

[rubberduck-vba/Rubberduck] retailcoder edited comment on issue #5644: ImplicitVariantTypeInDeclarationList Inspection

> Would/should this not be already covered by VariableTypeNotDeclared?

[rubberduck-vba/Rubberduck] BZngr created comment on issue #5644: ImplicitVariantTypeInDeclarationList Inspection

[rubberduck-vba/Rubberduck] BZngr closed issue #5644: ImplicitVariantTypeInDeclarationList Inspection

@IvenBach try a conditional breakpoint in the Declaration constructor to break during (well, after actually) the UDT resolution, and walk up the call stack and see where the accessibility goes Public (from Implicit?)

Break time. Not making any progress...

I realize how much my dependence on visually seeing the code as text hinders my ability to work through the code.

Faster when I took your advice Mug: github.com/rubberduck-vba/Rubberduck/blob/next/….

visibility : PRIVATE | PUBLIC | FRIEND | GLOBAL; may be limited.

Oh.... Check if not null Public, then if not null Private, else Implicit.

[rubberduck-vba/Rubberduck] IvenBach synchronized pull request #5643: Include enums in ImplicitPublicMemberInspection

[rubberduck-vba/Rubberduck] IvenBach synchronized pull request #5643: Include enums in ImplicitPublicMemberInspection

[rubberduck-vba/Rubberduck] build for commit ee7787e0 on unknown branch: AppVeyor build succeeded

[rubberduck-vba/Rubberduck] IvenBach synchronized pull request #5643: Include enums in ImplicitPublicMemberInspection

Progress is there. Slow but consistent.

[rubberduck-vba/Rubberduck] IvenBach assigned IvenBach to issue #5642: Flag implicitly public enumerations as such

@IvenBach github.com/rubberduck-vba/Rubberduck/pull/5634 for tomorrow. Tonight its bed time.

[rubberduck-vba/Rubberduck] build for commit 56c56fb9 on unknown branch: AppVeyor build succeeded

[rubberduck-vba/Rubberduck] build for commit 6282a3a4 on unknown branch: AppVeyor build succeeded

[rubberduck-vba/Rubberduck] APoint2020 starred us

When I attempt a build of the latest I get: "Error occurred while restoring NuGet packages: The operation failed as details for project Rubberduck.InternalApi could not be loaded."

I'm using VS 2017 15.9.26 and have a number of NuGet packages with available updates. I'm guessing it's time to update one or more of these?

More precisely, the message above is not generated during a build. It is generated while loading the solution.

The first error during an attempted build is the CodeAnalysis project: "error NETSDK1050: The version of Microsoft.NET.Sdk used by this project is insufficient to support references to libraries targeting .NET Standard 1.5 or higher. Please install version 2.0 or higher of the .NET Core SDK."

@BZngr try VS2019

Not sure where we stand with .NET Core, but IIRC we're slated to drop VS2017 soon, if it's not done already

[rubberduck-vba/Rubberduck] retailcoder added label PR-Status: Conflicting to pull request #5618: Move resources out of RubberduckUI into CodeAnalysisUI

[rubberduck-vba/Rubberduck] retailcoder merged pull request #5612: EncapsulateFieldRefactoring - Fix false-positive conflict detections involving 'Me' qualifier from BZngr/Rubberduck/EF_ConflictFinderMeQualifier into...

rubberduck-vba/Rubberduck/next

[rubberduck-vba/Rubberduck] BZngr pushed commit 90946e70 to next: Fix false-positive conflict detections involving 'Me' qualifier

[rubberduck-vba/Rubberduck] BZngr pushed commit 9d827fe1 to next

[rubberduck-vba/Rubberduck] BZngr pushed commit 86ebf776 to next: Add tests demonstrating both conflict and non-conflict results

[rubberduck-vba/Rubberduck] BZngr pushed commit 8b5f9bbb to next: Refactor tests to support parallel execution

[rubberduck-vba/Rubberduck] BZngr pushed commit 3b59eb0c to next: Merge branch 'rubberduck-vba-next' into EF_ConflictFinderMeQualifier

[rubberduck-vba/Rubberduck] BZngr pushed commit 1e9cf7b2 to next: Fix compile errors following merge

[rubberduck-vba/Rubberduck] web-flow pushed commit 4dc9bab1 to next

[rubberduck-vba/Rubberduck] SmileyFtW created comment on issue #4169: New Unit Test Added inside existing Unit Test

[rubberduck-vba/Rubberduck] retailcoder commented on Rubberduck.Core/UI/ToDoItems/ToDoExplorerViewModel.cs of pull request #5627: Add filtering to ToDoExplorer

@MathieuGuindon would be the case once we merge #5239

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created draft prerelease Prerelease-v2.5.1.5675

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot prereleased draft prerelease Prerelease-v2.5.1.5675

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot published prerelease Prerelease-v2.5.1.5675

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created tag Prerelease-v2.5.1.5675

[rubberduck-vba/Rubberduck] build for commit 4dc9bab1 on next: AppVeyor build succeeded

@this After loading the latest version, my NuGet package manager adds an update for System.IO.Abstraction to my list of updates for the solution. It is not in the update list when I load an earlier branch. Maybe the InternalApi PR requires this update?

To version 13.2.2

@BZngr I did merge the System.IO.Abstraction PR earlier (few days)

@MathieuGuindon dropping 2017 is required for .NET 5

but we're not there yet AFAIK

[rubberduck-vba/Rubberduck] retailcoder closed issue #5610: Variable not referred to - false positive?

[rubberduck-vba/Rubberduck] retailcoder merged pull request #5640: Count for loop assignment as variable usage from MDoerner/Rubberduck/CountForLoopAssignmentAsVariableUsage into...

rubberduck-vba/Rubberduck/next

[rubberduck-vba/Rubberduck] MDoerner pushed commit 9f5e9d46 to next: Stop generating variable not used results for variables used as For Next counter

[rubberduck-vba/Rubberduck] MDoerner pushed commit 616999cb to next: Merge branch 'next' into CountForLoopAssignmentAsVariableUsage

[rubberduck-vba/Rubberduck] web-flow pushed commit 06f5b033 to next

Ok so in theory VS2017 still works then

Thanks =)

Also I did my resume and gave it to a recruiter at last, and something something might start a new job in 2021

woot woot

=)

Go Mug! Fill yourself with some coffee, tea or hot chocolate!!

that sounded better in my head...

[rubberduck-vba/Rubberduck] Vogel612 created comment on issue #4169: New Unit Test Added inside existing Unit Test

> @SmileyFtW that's ... almost three thousand builds ago ...

@Duga I mean ...

@MathieuGuindon Yeah Rubberduck.Core.csproj was modified and added System.IO.Abstaction. I'll update that package.

@Vogel612 I just downloaded and installed 2.5.1.5675. .5663 is the most previous release. The original issue is on a 2000 or so old build...

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot prereleased draft prerelease Prerelease-v2.5.1.5676

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created draft prerelease Prerelease-v2.5.1.5676

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot published prerelease Prerelease-v2.5.1.5676

[rubberduck-vba/Rubberduck] rubberduck-vba-releasebot created tag Prerelease-v2.5.1.5676

[rubberduck-vba/Rubberduck] build for commit 06f5b033 on next: AppVeyor build succeeded

@Vogel612 ah! your comment linked back to the post directly above. I were cornfuzed...

@BZngr since the PR was a while back, they probably released a nuget update. No harm in keeping it up to date, I think.

@MathieuGuindon better stock up on those purple velvet suits! They ain't cheap!

Seriously I hope it works out for you. :)

@this I've held off updating NuGet packages. The package manager indicates I have the right version of System.IO.Abstractions for each project. I've updated to the latest VS2017 available but still...no joy. Loading the solution generates "Error occurred while restoring NuGet packages: The operation failed as details for project Rubberduck.Parsing could not be loaded." - I think this is at the root of it.

um, can't remember if I added abstractions ot parsing but I would think / hope not

since parsing shouldn't have to do any IO. at least in theory

No - it was not added to parsing. I've got something else going on I think.

you tried cleaning & rebuilding, right?

Yes - that's when I get errors directing me to "Please install version 2.0 or higher of the .NET Core SDK.". But I'm starting to think that may just be a downstream effect since the NuGet package manager does not succeed when the solution is loaded.

Rubberduck.Main and Rubberduck.Tests fail to build.

Also Parsing, CodeAnalysis, and Deployment

it cascades. If Parsing doesn't build, the downstream won't, either.

i'd clean, and build the parsing only. Set error list to show only the build error rather build + intellisense

Hmmm...by itself, building Parsing by itself just succeeded. I guess I'll press on one at a time.

My VS2019 is borked and won't lemme build. I've gone back to using 2017 for the time being.

currently the grass is not much greener back here either :)

~.~

I upgraded VS2019 and it just won't build. There's no way to get a previous community edition either.

@IvenBach takes another trip around the borken record...

all I can say it builds on my VS2019

All the errors are Microsoft.FooBar and won't take me to the specific line.

feels like we're the villagers in that FF3 where nobody knows what the time is

ZoZo.

But at least they have magic.

I thought we were to wait on using VS2019 - no?

right now it should work on both 2017 and 2019

but when the WinForm/WPF SDK PR is merged, then 2017 definitely won't work

should work hehe

that's because Microsoft has a flag dontBuildIfItsIvenBach

ahh...I will have to investigate with VS2019 when I can get back.

My struggles with VS and building are well known.

So I'm clear... @BZngr can build on 2017 but not 2019. @IvenBach can build on 2017 but not 2019?

VS2017 = Buildable
VS2019 = Borked with 14,000 errors.

Iven, and is 2019 up to date? there were few versions of 2019 where it doesn't work

Only 14k? Whacha complaining about? Get busy and fix 'em!!

I think it was 16.3 or 16.4, but I'm not sure.

VS2019 v16.8.2

My VS2019 is currently at 16.7.7 but yeah. I'm behind the latest (as usual)

Abbreviated list of errors.

CA1707	Microsoft.Naming : Remove the underscores from member name 'ResolverTests.PSetSpecialForm_IsReferenceToLocalVariable()'.
CA1001	Microsoft.Design : Implement IDisposable on '_Extension' because it creates members of the following IDisposable types: 'BeepInterceptor'. If '_Extension' has previously shipped, adding new members that implement IDisposable to this type is considered a breaking change to existing consumers.
CA1002	Microsoft.Design : Change 'List<CultureInfo>' in 'Locales.AvailableCultures' to use Collection<T>, ReadOnlyCollection<T> or KeyedCollection<K,V>

Contains only distinct error numbers.

uh. are they errors?

those look like hints

did you ahve it set to convert warning to errors, maybe?

They are coming up as errors, preventing a build.

there's a VS setting that would force those warnings as errors.

I didn't change a setting. Possible it was changed when it updated. I know it wasn't Iven.

Any clue where to change that setting?

I'm pretty sure those it wasn't supposed to be an error.

I've tried looking but my search-fu is weak on this one.

docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/… I can locate it in docs. Just not how to turn it off or make it a warning instead.

weird - it's not a VS setting but a csproj setting.

which should then show up in git commits.

right-click any csproj, properties, then Build pane

there, you'll see options to treat warnings as errors.

on mine, only 2 should be an error: NU1605; CS1591

i wonder if it's a code analysis setting...

@this I've only worked with VS2017 thus far. Cannot build.

RD.CodeAnalysis: Treat warnings as errors>Specific warnings: NU1605.

@BZngr check the vs2019 version.

@IvenBach I have the same thing.

I'm checking each one #JustInCase

Like I said, if that was changed by mistake, it'd definitely show up in the git commit / working tree history.

since it'll have to show up in the csproj file

I am trying to remember whether VS had a code analysis setting that might cause warning to be errors

Every project has Specific Warnings set.

Hrm....

but the warning level changes on some of them

I think that's right. but you can see that your errors aren't listed.

In fact, in sample you listed, they all start with CA*, which indicate it's a code analysis result

Which makes me think it's something that auto updated.

What does your code analysis tab say?

all I have is 2 chekboxes, both checked

Under All analyzers?

If they were actually set as warnings instead of errors then others would have a result. Do you see any of those CA* as warnings?

i have 312 warnings but none that matches the warnings you had

Under docs.microsoft.com/en-us/dotnet/fundamentals/code-analysis/… it goes over how to suppress the message

WRT VS2019 not being able to build it affects both work and home systems that updated.

@BZngr what version of 2019 are you using?

Big bowl of WTF this morning developercommunity2.visualstudio.com/t/…: Build twice and it succeeds.

@IvenBach I've yet to use it at all.

@IvenBach sorry confused, what did you do? I see mulitple solutions there

but that also explains why I didn't have that problem because i'm still on 16.7.7

that does not inspire confidence. I just want stability, MSFT. Is that too much to ask for?

@this yes

@this building twice. First time fails. Build again and it succeeds.

Ooookay.

[rubberduck-vba/Rubberduck] SmileyFtW created comment on issue #4169: New Unit Test Added inside existing Unit Test

> @Vogel612 When I go to the Pre releases it appears to be the latest. What am I missing?

[rubberduck-vba/Rubberduck] Vogel612 created comment on issue #4169: New Unit Test Added inside existing Unit Test

> hm ... I was going off of Iven's version specification. Apparently the latest prerelease is 2.5.1.5676, which is mostly because we had two new releases since you commented originally... Soooo.... I said some nonsense right there...

@Vogel612 Ah, ok.. it just looked and see that there are two that were released in the last 3-4 hours... <G>

yea

the issue probably was that Iven was comparing to a local dev build

which has a different build number

but generally speaking the last of the four numbers is monotonically increasing across all releases

there was a reset for that number some while back, but ...

[rubberduck-vba/Rubberduck] MDoerner created comment on issue #5636: False positive "Procedure not used" in Outlook "ThisOutlookSession"

OK, usually questions at DIY look like they were written by uneducated 10 year olds who've stolen their big sister's phone and are posting leet kewl stufs FIRST!!!11!!11!one. This one, however, has expanded my vocabulary (in a good way)!

lololol

@FreeMan #ProTip: Hire an expert. yes they charge an arm and a leg but once you discount the lost labor time and the hours spent in remedying the oopsies, the expert comes out as a stunning basement bin bargin in contrast.

That's the trouble - people look at the material cost and think "gee, they charge X an hour! I could save that much money if I just bought it myself and do it myself." That would be a true statement as long as you actually knew what you are doing. Rarely do they factor in their personal labor as a "billable" time. (think your significant other is going to let you trot off to work without hot water? Gonna have to call that one in sick...) TANSTAAFL

@this Well, yeah, but there's a satisfaction in doing it yourself. We built our own garage nearly 30 years ago. Hired someone to dig the foundation and pour the concrete. Did everything else from there. h'aint collapsed yet!

Actually, had a friend of the BIL come over and he ran power to the garage for us. Licensed electrician, working for one of the major commercial electrical places in town. Did a totally non-code-compliant install. Had no idea until recently when I'd been reading on DIY and realized... Hey, waitacottonpickinminute....

I'm pretty sure my wiring from the panel to the everything else is more compliant than his wiring from one panel to the next.

@FreeMan I bet that doing the same thing would be impossible today. I understand they've been regulating a teensy weensy bit more than back then.

No, not really. Of course, we're in a tiny little berg and our inspections are mostly a matter of the guy coming over, wandering around and "yeah, looks OK"... :)

(at least in suburbia - if you're out in the sticks, aint no steenking pencil pushers around telling you what you can & can't do on your private property)

Yeah, if you're talking HOA, no way in the world! But if you're just talking legalities and passing inspections, not really a problem. We literally learned everything by watching This Old House and Hometime on PBS.

Had no idea what we were doing, just winged it and used common sense.

I had a friend who did an improvement on a 2nd house for which they planned to expand the 2nd floor. A nosy neighbor did not like what they were doing to the old house and even called the permits on them. Almost fined them $10K for not having the permits.

Some electrical issues where we're not meeting code (like 14/2 wire on a 20 amp breaker) that need to be remedied, but nothing significant

well... I never said we didn't pull permits!

;)

It helped that the friend had some code stuff (dont' remember exactly what) so it wasn't like he was totally cowboying it up.

there's no excuse for not meeting code these days. Too many resources too easily available, but it's not hard.

Yeah, I agree with at least meeting the code. But in some areas they'd regulate you to death where it's probably cheaper to let the house fall in disrepair and just move out.

LOL

as the old gippy used to say -- If it moves, tax it. If it moves too slowly, regulate it. If it stops moving, subsidize it.

[rubberduck-vba/Rubberduck] BZngr opened issue #5645: Getting RD to build in VS2019 v16.8.2

[rubberduck-vba/Rubberduck] bclothier created comment on issue #5645: Getting RD to build in VS2019 v16.8.2

> If you do that, does that also disable our custom code analyzers which currently treat any results as an error?

@Duga that's quite distressing - there were already unstable updates on the 16 series (I think on 16.1, then again on 16.3 & 16.4) that borked stuff and now this? Starting to think that QC is an idea at MSFT.

[rubberduck-vba/Rubberduck] BZngr created comment on issue #5645: Getting RD to build in VS2019 v16.8.2

> Yes - The "Directory.Build.props" file added in step one changes that behavior.

[rubberduck-vba/Rubberduck] bclothier created comment on issue #5645: Getting RD to build in VS2019 v16.8.2

> That is unfortunate. Currently, we use the custom code analyzer to prevent building when it's missing required elements for COM handling or for inspection XML. With that, it would get missed. If the appveyor's VM is updated to 16.8, and thus requires this workaround, it would be now possible to miss those stuff.

@Duga I may be wrong. The observable is that it avoids the thousands of warnings-as-errors we were experiencing. I'm not familiar with the custom code analyzers you are referring to - the flag may not affect them...so - I can only suggest you run a check to see if it has the effect you are concerned about.

that'd require me to update my 16.7.7 to 16.8.2 and I don't want to. LOL

I have no idea how to revert to 16.7.7 (nor do I want to try)

Good point!! :)

but testing this is easy. Just find any existing code with an inspection xml doc or ComVisible(true) attribute and comment it out

that should be enough to flag the custom code analyzers

thought to be super duper sure, rebuilding may be a good idea

@this Yeah...I guess I should be the guinea pig since I've no option but to press on with 16.8.2.

I'm glad you found a workaround though. Appveyor will probably catch the issues for now but I'm concerned about when Appveyor updates their VM image and we end up having to get the AV to ignore it

Just ran the content updater manually on work laptop, the website now knows of the newest pre-release build.. and downloads for 2.5.1 now say 5,777

Nice!

New content: rubberduckvba.com/QuickFixes/Details/DeclareAsExplicitType

Also: rubberduckvba.com/QuickFixes/Details/QualifyWithMe

@BZngr it might be useful to look into setting up an editorconfig to remove the warnings we're not using

there is some configuration to remove certain warnings (which is currently ignored by appveyor, but semi-effective in VS)

And the custom analyzers should have the option of explicitly being an Error diagnostic (instead of a warning diagnostic)

@this I deleted the XMLDocs for AssignedByValParameterInspection and did a clean and rebuild...no errors. If that is the test you are describing - then it has the unfortunate side-effect you were concerned about.

[rubberduck-vba/Rubberduck] Vogel612 created comment on issue #5645: Getting RD to build in VS2019 v16.8.2

@BZngr you could check all the Diagnostic.Create calls we're doing inside the analyzers and verify they have a DiagnosticDescriptorSeverity of Error

@Vogel612 I have to take off for a bit ATM. I'll work the things you're suggesting when I can get back to RD. TBH - I'm unfamiliar with any of the things you are suggesting - you may end up fielding a lot of questions. :)

I am also quite unfamiliar

I just had to mess around with diagnostics when I changed the csproj format

but that's... years ago at this point