Merge pull request #5938 from rubberduck-vba/releasebot-patch-appveyor-token

Update appveyor.yml

Acknowledge that module constants can have attributes

This required adding the corresponding contexts in the context listener and actually attaching them to the ValuedDeclaration.

Since only module constants can have attributes, a further level has been added in the grammar to reflect the distinction.

Merge pull request #5934 from MDoerner/FixVarDescOnConstant

Acknowledge that module constants can have attributes

> To add to this discussion and maybe help others who wonder why when they are clearly using 64bit Office they're getting memory issues:
I use 64bit Access (Office), and was getting consistent "out of memory" errors with my file sitting around 1GB, give or take. Originally thinking that 64bit is LAA, I didn't try the fix.

But on a whim, I ran the LAA tool on `VBE7.DLL`, `VBEUI.DLL`, `MSACCESS.EXE`, and the RD DLLs (specifically `RubberDuck.DLL`)

I may run it on the rest of the RD DLLs (p

> Alright. I did it. Was not able to change the flag; got a write error, in fact.

1. I unloaded and ran the tool to clear the value.
2. Restarted Access. RD ran slower and parsing took a while, and memory stayed around the 1GB mark.
3. Closed Access, ran the tool to set LAA flag.
4. Indicated no change (again).
5. Started Access, RD parses faster.

I cannot explain it. But, it clearly did something. RD info:
Version 2.5.2.5994
OS: Microsoft Windows NT 10.0.19042.0, x64
Host Produ

> Alright. I did it. Was not able to change the flag; got a write error, in fact.

1. I unloaded and ran the tool to clear the value.
2. Restarted Access. RD ran slower and parsing took a while, and memory stayed around the 1GB mark. I was not able to induce the memory error, but the memory in use stayed below 1GB; but I did notice a performance degradation.
3. Closed Access, ran the tool to set LAA flag.
4. Indicated no change (again).
5. Started Access, RD parses faster.

I cannot e

> Sure thing!

Direct link to DL: [modLargeAddressAware.zip](https://codekabinett.com/download/modLargeAddressAware.zip)
Page source: [The /LARGEADDRESSAWARE (LAA) flag demystified](https://codekabinett.com/rdumps.php?Lang=2&targetDoc=largeaddressaware-msaccess-exe)

> Sure thing! I ran this via Excel (because you can't run this in the same Application you're trying to set), if that helps any.

Direct link to DL: [modLargeAddressAware.zip](https://codekabinett.com/download/modLargeAddressAware.zip)
Page source: [The /LARGEADDRESSAWARE (LAA) flag demystified](https://codekabinett.com/rdumps.php?Lang=2&targetDoc=largeaddressaware-msaccess-exe)

> I agree, I am also flummoxed. But in my anecdotal test size of 1, it seemed to work.

I'll keep an eye on memory use for a bit and see if anything changes, but, other than my machine was placebo satisfied, I've got nothing.

> Try editbin from Visual Studio, I use this to set the flags on my software.
And compare the files between before and after editing it.

> I used `dumpbin.exe` to check for the LAA flag on all DLL files in the RD directory. Then I listed only those not LAA aware to get a shorter list.

Here is what I get:

```
EasyHook32.dll is NOT LAA aware
EasyLoad32.dll is NOT LAA aware
ICSharpCode.AvalonEdit.dll is NOT LAA aware
Microsoft.Expression.Interactions.dll is NOT LAA aware
office.dll is NOT LAA aware
stdole.dll is NOT LAA aware
System.Windows.Interactivity.dll is NOT LAA aware
```

NOTE: All the main RD DLL files appea

> **Rubberduck version information**
The info below can be copy-paste-completed from the first lines of Rubberduck's log or the About box:

2022-01-24 15:41:24.2324;TRACE-2.5.2.5906;Rubberduck.Common.LogLevelHelper;
Rubberduck version 2.5.2.5906 loading:
Operating System: Microsoft Windows NT 10.0.19043.0 x64
Host Product: Microsoft Office x64
Host Version: 16.0.14729.20260
Host Executable: EXCEL.EXE;


**Description**
When opening a specific file i get a parse error. The VBA co

> That is very interesting. The parser seems to fail on `Option Explicit` when expecting an `<EOF>`. This suggests that you have declared the Option explicit later than the parser expects.

Since this is the latest green release it's impossible for the recent changes to the grammar to be responsible for this issue, which implies that this has been an issue for a bit longer than I'd like... Could you check whether (and how) moving the `Option Explicit` in the module `ThisWorkbook` affects this