Delete useless aliases in astcodegen.d

[RazvanN7]

The aliases were present to workaround a compiler bug which was fixed by : #7668 but the update couldn't be done because the bootstrapping version of the compiler did not benefit from the fix. Now that the bootstrapping compiler was bumped to 2.079 we can delete them.

Later edit: Looks like the other bots are still using old versions of the compiler.

[dlang-bot]

Thanks for your pull request and interest in making D better, @RazvanN7! We are looking forward to reviewing it, and you should be hearing from a maintainer soon.
Please verify that your PR follows this checklist:

• My PR is fully covered with tests (you can see the annotated coverage diff directly on GitHub with CodeCov's browser extension
• My PR is as minimal as possible (smaller, focused PRs are easier to review than big ones)
• I have provided a detailed rationale explaining my changes
• New or modified functions have Ddoc comments (with Params: and Returns:)

Please see CONTRIBUTING.md for more information.

---

If you have addressed all reviews or aren't sure how to proceed, don't hesitate to ping us with a simple comment.

Bugzilla references

Your PR doesn't reference any Bugzilla issue.

If your PR contains non-trivial changes, please reference a Bugzilla issue or create a manual changelog.

Testing this PR locally

If you don't have a local development environment setup, you can use Digger to test this PR:

dub fetch digger
dub run digger -- build "master + dmd#8445"

[wilzbach]

Later edit: Looks like the other bots are still using old versions of the compiler.

We can easily upgrade CircleCi and AppVeyor, but now we're already using the latest release of GDC.

[wilzbach]

@RazvanN7 I'm sorry, but as long as there's no GDC released with the 2.079 frontend, I guess we will have to wait a long time on this.
According to this roadmap I guess the GCC 9 release will be in a year or so:

https://gcc.gnu.org/develop.html#timeline

       +-- GCC 6 branch created --------+
       |                                 \
       v                                  v
  GCC 7 Stage 1 (starts 2016-04-15)        GCC 6.1 release (2016-04-27)
       |                                    \
       |                                     v
       |                                   GCC 6.2 release (2016-08-22)
  GCC 7 Stage 3 (starts 2016-11-14)           \
       |                                       v
       |                                   GCC 6.3 release (2016-12-21)
  GCC 7 Stage 4 (starts 2017-01-20)             \
       |                                         v
       |                                   GCC 6.4 release (2017-07-04)
       +-- GCC 7 branch created --------+        
       |                                 \  
       |                                  v
  GCC 8 Stage 1 (starts 2017-04-20)        GCC 7.1 release (2017-05-02)
       |                                    \
       |                                     v
       |                                   GCC 7.2 release (2017-08-14)
  GCC 8 Stage 3 (starts 2017-11-18)           \
       |                                       v
  GCC 8 Stage 4 (starts 2018-01-15)        GCC 7.3 release (2018-01-25)
       |
       +-- GCC 8 branch created --------+        
       |                                 \  
       |                                  v
  GCC 9 Stage 1 (starts 2018-04-25)        GCC 8.1 release (2018-05-02)
       |
       v

However, there's very good news. Ian has made massive progress on GDC and there's a GDC PR which merge the 2.081 frontend into GDC (D-Programming-GDC/gdc#683).

I will be closing this for now to clear up the PR queue, but I created an issue (https://issues.dlang.org/show_bug.cgi?id=19063), s.t. it's not forgotten and also tagged it with the "Phantom Zone" label.

[ibuclaw]

According to this roadmap I guess the GCC 9 release will be in a year or so:

It will likely be GCC 10 as I have no intention of submitting a self hosted compiler as the first release. Even then, I'd rather keep future releases compilable with prior for a certain period - 2 or 3 releases sounds reasonable to me.

there's a GDC PR which merge the 2.081 frontend into GDC

It starts a process continuous synchronisation with the dmd/stable branch. What release it will be will in gcc will depend on what dmd front-end version release aligns with gcc schedule.

[ibuclaw]

By the way, you could raise a bug report in gdc to backport the dependant fix to the C++ branch (2.076 support in gdc is comprised of all ddmd changes converted into C++).

If the required change is small and contained, then you needn't wait so long. :-)