Looks about right to me, as an extension of D124413 - but I would appreciate it if ayzhao@ can weigh in here, since that was his patch.

Looks good to me at a glance. Is this something we should support in MASM as well?

In D140679#4018896, @glandium wrote:

@epastor could you land this for me?

Thanks for catching this alias!

Fix a missing negation

In D131522#3713909, @thakis wrote:

Thanks!

I wonder if ml allows nested procs to refer to the parameters of the outer proc – then we'd have to handle activation records like gcc creates them for its nested functions.

But we don't even implement parameters for proc at all, so that's moot for now :)

Add support for case-insensitive PROC/ENDP matching

Add tests

Fix remaining nit

Address nits

Fixing test

Add simple test

Removing another accidental reformat

Addressing feedback

Fix collision with tombstone entry, and also remove one more bit of handling for GNU-as-style directional labels

Small update to comments

Addressing last comment

Rebase to HEAD

In D128944#3623568, @rnk wrote:

Should these be unnamed labels so they don't appear in the COFF file symbol table? I'm guessing ml64 doesn't produce symbols for these labels, but correct me if I'm wrong.

If that is the case, I suggest:

• keep the counter
• store a vector of MCSymbols indexed by label counter
• use a getOrCreate operation to fill in that vector or read from it to handle support for forward references (@F)

Switch to the pre-existing anonymous label support. (Missed this in the first attempt!)

LGTM, but I'll defer to hans here since he's guided thus far.

In D126425#3545711, @hans wrote:

It appears to me that MASM doesn't care much about the file extension at all:

[test results omitted]

The fact that /Ta exists suggest maybe it did care at some point, but that may have changed.

Looks good to me, but probably make sure Hans agrees first.

I'm fine with this and want to remove my request for changes - but please make sure Hans approves as well.

Thanks!

In D109425#2989346, @peter.smith wrote:

In D109425#2989305, @epastor wrote:

This code is similar to code in AsmParser.cpp (https://github.com/llvm-mirror/llvm/blob/master/lib/MC/MCParser/AsmParser.cpp#L3344-L3351) - looks like that will probably need an update as well, to keep MaxBytesToFill from being interpreted as a pointer?

Yes, I managed to catch that one in D45961 that reference from llvm-mirror might be a little bit out of date. I think https://github.com/llvm/llvm-project/blob/main/llvm/lib/MC/MCParser/AsmParser.cpp#L3457 is where the code is now. Hope I've not missed something.

This code is similar to code in AsmParser.cpp (https://github.com/llvm-mirror/llvm/blob/master/lib/MC/MCParser/AsmParser.cpp#L3344-L3351) - looks like that will probably need an update as well, to keep MaxBytesToFill from being interpreted as a pointer?

Fix copy/paste error in test label

Rebase on parent

Add all-lowercase test for a mixed-case macro

Switch back to gmtime/localtime (not thread-safe, but in a generally-safe location - and more cross-platform)

Rebase on parent

Rebase on parent

Addressed feedback (and rebased on HEAD)

Add -timestamp and -utc flags to support deterministic builds

Restrict further to only named-variable references

Rebase on parent

Fix symbol usage bug

Rebase on parent

Fix accidental fold with the child commit

Fix an accidental import of MasmParser.cpp from a child commit

Rebase on parent

Rebase on parent

Address feedback (including clang-tidy)

In D104964#2853790, @thakis wrote:

Can you check if ml.exe allows defining a local variable overriding e.g. @Line? What happens then? Does it error? Can you add a test for that?

Error on redefinition of built-in symbols (matching ML.EXE)