« first day (2370 days earlier)      last day (54 days later) » 

12:00 AM
RELOAD!
[rubberduck-vba/Rubberduck] 1 opened issue. 3 issue comments.
[Minesweeper] Games Played: 99, Bombs Used: 46, Moves Performed: 14704, New Users: 5
 
12:18 AM
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.
 
> **What**

Inspect code for declaration lists that contain implicitly typed `Variant` variables and constants.

**Why**

It is easy for a user to declare a module variable (or constant) like `Public var1 As Long`, and then later insert another variable `Public var1, var2 As Long` assuming all is well. And, all appears _well_ because everything generally compiles and _works_ depending on how `var1` is used. If `var1` is later used as an argument for a `Long` parameter, the compile error
> After refactoring should each declaration be on its own line?
```vb
Public var1 as Long
Public var2 as Long
```

Having them each on their own line to begin with would have helped illustrate that the first had no declared type.
 
12:40 AM
@IvenBach another typo in parSer
That concludes by saving all the states of the tokens for the parsed module.
 
> 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.
 
1:43 AM
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?
 
2:29 AM
> `VariableTypeNotDeclared` would definitely flag the same set of variables. The difference here is that this inspection/quickfix is constrained to un-typed variables declared in a list where only the last variable has a `non-Variant` As Type. The inspection/quickfix _assumes_ it's most likely that the user intended for all variables to have the same `As Type` as the _last_ variable.

wow...Now that I've written the above, I realize my recent (and apparently already forgotten!?) `DeclareAs
 
@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?)
 
2:56 AM
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.
 
 
2 hours later…
4:47 AM
Faster when I took your advice Mug: github.com/rubberduck-vba/Rubberduck/blob/next/….
Oh.... Check if not null Public, then if not null Private, else Implicit.
 
6:13 AM
[rubberduck-vba/Rubberduck] build for commit ee7787e0 on unknown branch: AppVeyor build succeeded
 
Progress is there. Slow but consistent.
 
@IvenBach github.com/rubberduck-vba/Rubberduck/pull/5634 for tomorrow. Tonight its bed time.
 
6:36 AM
[rubberduck-vba/Rubberduck] build for commit 56c56fb9 on unknown branch: AppVeyor build succeeded
 
7:00 AM
[rubberduck-vba/Rubberduck] build for commit 6282a3a4 on unknown branch: AppVeyor build succeeded
 
 
4 hours later…
10:35 AM
 
 
2 hours later…
12:58 PM
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."
 
 
1 hour later…
2:27 PM
@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] BZngr pushed commit 90946e70 to next: Fix false-positive conflict detections involving 'Me' qualifier
Make reference qualifier predicate function local

Addresses PR comment.
[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
Merge pull request #5612 from BZngr/EF_ConflictFinderMeQualifier

EncapsulateFieldRefactoring - Fix false-positive conflict detections involving 'Me' qualifier
> FWIW I am seeing this on
Version 2.5.1.5663
OS: Microsoft Windows NT 10.0.18363.0, x64
Host Product: Microsoft Office x86
Host Version: 16.0.13328.20356
Host Executable: EXCEL.EXE
 
2:56 PM
@MathieuGuindon would be the case once we merge #5239
 
3:11 PM
@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
 
3:27 PM
@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] 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
 
Ok so in theory VS2017 still works then
 
Merge pull request #5640 from MDoerner/CountForLoopAssignmentAsVariableUsage

Count 'For' loop variable as self-referencing assignment, removes inspection false positive.
 
Thanks =)
In other news, the SO ad is consistently doing roughly 15 clicks/day and that's crazy (the 9.x average includes the 2 months no ads were served)
Also I did my resume and gave it to a recruiter at last, and something something might start a new job in 2021
4
 
3:35 PM
woot woot
 
Go Mug! Fill yourself with some coffee, tea or hot chocolate!!
that sounded better in my head...
 
> @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.
 
3:52 PM
@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...
 
22 hours ago, by Vogel612
on that note: we should consider doing another green release, because there's some really nice new features
 
4:09 PM
@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
 
4:26 PM
No - it was not added to parsing. I've got something else going on I think.
 
you tried cleaning & rebuilding, right?
 
4:41 PM
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
 
4:59 PM
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
 
5:05 PM
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
 
5:07 PM
that's because Microsoft has a flag dontBuildIfItsIvenBach
3
 
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
 
5:12 PM
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?
 
5:14 PM
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...
 
5:19 PM
@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
 
5:24 PM
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
 
5:41 PM
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?
 
6:01 PM
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.
 
6:52 PM
> @Vogel612 When I go to the Pre releases it appears to be the latest. What am I missing?
> 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 ...
 
7:40 PM
> Fixing this in a perfect way might require to give up on the use of the hash set.
However, since most built-in declarations come from references only using English names, I would like to suggest to simply change all identifiers to lower case for hashing.
 
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)!
3
Q: How to dry out a soaked water heater (and restore a novice plumber's dignity)?

universalhandleSuppose a novice plumber -- a completely hypothetical novice plumber -- removed the top heating element in their electric water heater before the tank had sufficiently drained, resulting in about a gallon of water spurting out not only into the basement but also down the inside of the device, soa...

 
lololol
 
8:07 PM
@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
 
 
1 hour later…
9:35 PM
@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.
 
9:41 PM
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.
 
 
1 hour later…
10:50 PM
> Well..VS2019 16.8.2 seems entirely unusable after initial install. It is as though the project's Property `Treat Warnings as Errors` setting is always `True` regardless of the actual setting in the `.csproj` file.

The steps I found to get to a successful build were:
**1.** Create a file "Directory.Build.props" in the `Rubberduck` folder (top of the repo) with the following content:

```
<Project>
<PropertyGroup>
<CodeAnalysisTreatWarningsAsErrors>false</CodeAnalysisTreatWarnings
> 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.
 
> Yes - The "Directory.Build.props" file added in step one changes that behavior.
> 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!! :)
 
11:04 PM
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!
 
11:13 PM
@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.
 
> Could you try adding an `.editorconfig` file in the basedirectory with the following content, if the error around that CA0001 reoccurs?

```
[*.{cs,vb}]
dotnet_diagnostic.CA0001.severity = none
```

Other than that you could reenable the "warnings as errors" and add all diagnostics that currently produce unwarranted results to that file.
That probably includes the analyzers yielding `MSB4011`, `IDE1001`, `CS7035` and `AL1053`, which should currently not yield results in VS either.
 
@BZngr you could check all the Diagnostic.Create calls we're doing inside the analyzers and verify they have a DiagnosticDescriptorSeverity of Error
 
11:29 PM
@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
 

« first day (2370 days earlier)      last day (54 days later) »