Rename cross compilation related defines

[sdmaclea]

Rename cross compilation related defines

To drive explicit and consitent usage of the terms TARGET and HOST, and
to remove usage of reserved identifiers, rename several macro defines

  _ARM_                -> HOST_ARM       in src/coreclr
  _ARM64_              -> HOST_ARM64     in src/coreclr
  _AMD64_              -> HOST_AMD64     in src/coreclr
  _X86_                -> HOST_X86       in src/coreclr
  _HOST_UNIX_          -> HOST_UNIX      in src/coreclr
  _HOST_AMD64_         -> HOST_AMD64     in src/coreclr
  _HOST_ARM64_         -> HOST_ARM64     in src/coreclr
  _HOST_ARM_           -> HOST_ARM       in src/coreclr
  _HOST_X86_           -> HOST_X86       in src/coreclr
  DBG_TARGET_AMD64     -> TARGET_AMD64   in src/coreclr
  DBG_TARGET_ARM64     -> TARGET_ARM64   in src/coreclr
  DBG_TARGET_ARM       -> TARGET_ARM     in src/coreclr
  DBG_TARGET_X86       -> TARGET_X86     in src/coreclr
  _TARGET_AMD64_       -> TARGET_AMD64   in src/coreclr
  _TARGET_ARM_         -> TARGET_ARM     in src/coreclr
  _TARGET_ARM64_       -> TARGET_ARM64   in src/coreclr
  _TARGET_X86_         -> TARGET_X86     in src/coreclr
  _TARGET_ARMARCH_     -> TARGET_ARMARCH in src/coreclr
  _TARGET_XARCH_       -> TARGET_XARCH   in src/coreclr
  _HOST_64BIT_         -> HOST_64BIT     in src/coreclr
  BIT64                -> HOST_64BIT     in src/coreclr
  _TARGET_64BIT_       -> TARGET_64BIT   in src/coreclr
  DBG_TARGET_64BIT     -> TARGET_64BIT   in src/coreclr
  HOST_IS_WINDOWS_OS   -> HOST_WINDOWS   in src/coreclr
  PLATFORM_UNIX        -> HOST_UNIX      in src/coreclr/*.cmake
  PLATFORM_WINDOWS     -> HOST_WINDOWS   in src/coreclr/*.cmake
  _TARGET_MAC64        -> TARGET_OSX     in src/coreclr
  FEATURE_PAL          -> TARGET_UNIX    in src/coreclr
  _TARGET_UNIX_        -> TARGET_UNIX    in src/coreclr
  _TARGET_WINDOWS_     -> TARGET_WINDOWS in src/coreclr
  PLATFORM_UNIX        -> TARGET_UNIX    in src/coreclr

The first commit is purely a big search and replace.
The second commit is changes necessary to fix compilation issues.
The third commit is clang-format of the src/jit directory.

A future PR will rename some of the TARGET_* to HOST_* and vice-versa as needed. This mostly a brute force search and replace.

[jkotas]

I would be nice to delete FeaturePal as well (in future PR).

[jkotas]

BIT64 -> HOST_64BIT

We have choose TARGET_ as the default in all other place. Why use HOST_ as the default for this one?

[sdmaclea]

BIT64 -> HOST_64BIT

We have choose TARGET_ as the default in all other place. Why use HOST_ as the default for this one?

It was currently set based on the host architecture. It looks wrong in most places, but I wanted to make this mostly a non-functional change. Given the JIT/crossgen supports cross bitness builds, I didn't want to mess with this here.

I also switched the PLATFORM_UNIX to map to HOST_UNIX on the similar rationale.

[jkotas]

Ok, hope most them are going to be flipped to be TARGET_XXX in follow up work. I see places in the current delta where the HOST_XXX and TARGET_XXX mixes within same function or file are pretty confusing.

[sdmaclea]

I certainly want to minimize HOST_XXX instances. They seem problematic outside the PAL. My guess is they are only likely to be right in JIT and zapper. I will definitely audit them.

[sdmaclea]

I had originally been doing the bulk edit replaces in my editor. Turns out my editor was skipping some files for some reason....

Anyways I decided it was less error prone to script this. So I wrote a bash/git/sed script to replace a single editor within a git subtree. Then I wrote a script for all the bulk edits.

I kept the commits more separate to ease review burden. The bulk search replace are separate commits.

The manual edits are separate commits.

I replaced the BIT64 rename to TARGET_BIT64 except in cmake, zap and jit (which had no references).

[BruceForstall]

fwiw, this change deserved to be (and still deserves to be) much more widely before being merged. Anyone with in-progress changes that added architecture-specific code (for example), then rebased, might not get the behavior they expect because previously-working #ifdef _TARGET_ARM64_ would now be dead code.

@dotnet/jit-contrib fyi: many global #ifdefs have changed names.

Also, can we change TARGET_OSX to TARGET_MACOS? Apple replaced the name OSX with macOS in 2016.

[jkotas]

Also, can we change TARGET_OSX to TARGET_MACOS?

There is discussion about it here: #31659 (comment) .

We have OSX name in the number of places today that we cannot change (e.g. https://docs.microsoft.com/en-us/dotnet/api/system.runtime.interopservices.osplatform.osx?view=netframework-4.8).

If we want to change it to something, I would vote for DARWIN. DARWIN should be immune to marketing whims.

[AndyAyersMS]

Can we make the old names cause errors for some interim period, so it's more obvious they won't work anymore? Otherwise stuff may just silently get dropped.

[CarolEidt]

I filed #31732 to clean up some inconsistencies in the JIT

[sdmaclea]

@dotnet/jit-contrib My apologies for not socializing this earlier. I had been concerned that my PR would shear with respect to master. That somehow I would have missed a rename.... I checked immediately after I merged so that I could prevent an outage. I didn't really anticipate the possibility that other PRs might go in after w/o having merge conflicts with this one....

@AndyAyersMS I am not sure how to make use of an undefined macro cause a build break.

Something like

#define _TARGET_ARM_ static_assert(BadDefine != BadDefine, "_TARGET_ARM_ macro is obsolete.  Use TARGET_ARM")

Might work in some circumstances, but not in all. I don't think it would work in the most common cases. Particularly:

#ifdef _TARGET_ARM_

#if defined(_TARGET_ARM_)

[erozenfeld]

Will
#pragma deprecated("_TARGET_ARM_")
work?
From https://docs.microsoft.com/en-us/cpp/preprocessor/deprecated-c-cpp?view=vs-2019
You can deprecate macro names. Place the macro name in quotes or else macro expansion will occur.

[lpereira]

For non-MSVC compilers, that #pragma won't work. In C (from C99 onwards at least), there's _Pragma(), and using it like so works in GCC and (probably) Clang:

#define WARN(msg) WARN2(GCC warning msg)
#define WARN2(s) _Pragma(#s)
#define DEPRECATE_MACRO WARN("Macro is deprecated")

And then use it like so:

#define _TARGET_ARM_ DEPRECATE_MACRO

I don't know, however, if there's something similar for C++ or even MSVC, though.

[janvorli]

While this mechanism works with clang, it doesn't help our purpose. The problem is that it only warns for #if _TARGET_ARM_, but not for #ifdef _TARGET_ARM_. The latter is used in all the cases we have. Unfortunately, I don't see any way to create a warning for the #ifdef usage case.