Add `TEST_OUTPUT` in fail1.d to fail9.d
Add `TEST_OUTPUT` in fail11.d to fail50.d
Add `TEST_OUTPUT` in fail51.d to fail99.d
Add `TEST_OUTPUT` in fail100.d to fail150.d
Add `TEST_OUTPUT` in fail152.d to fail200.d
Add `TEST_OUTPUT` in fail207.d to fail250.d
Add `TEST_OUTPUT` in fail251.d to fail299.d
Add `TEST_OUTPUT` in fail301.d to fail355.d
Update message changed by fixing issue 7175
Update message changed by merging pull request #2925 from WalterBright/redo-number-lexer
Merge pull request #2929 from yebblies/impcnv64

[DDMD] Replace implicit narrowing conversions with explicit casts (64-bit edition)
Issue 10905 - [CTFE] Fix [ICE](ctfeexpr.c line 355) with ulong2 in structs
Merge pull request #2913 from ibuclaw/issue8543

Issue 8543 - [CTFE] simd literals need better support
Merge pull request #2914 from ibuclaw/issue10312

Issue 10312 - [CTFE] ICE assigning to const vector decl
Merge pull request #2937 from ibuclaw/issue10905

Issue 10905 - [CTFE] Fix [ICE](ctfeexpr.c line 355) with ulong2 in structs
Fix clang warnings.

This pull request fixes some simple warnings which clang emits:
- mismatch between class and struct declaration
- mismatch between unsigned type and signed value
- missing virtual destructor
Merge pull request #2938 from redstar/warnings

Fix clang warnings.
fix Issue 5185 - Recursive template expansion error in class method

As the test casein 5185, `checkRecursiveExpansion` would prevent legitimate template instantiation.

If a template instance depends on the definition of itself, it is a true "recursion". But, a declaration sometimes can depend on the declaration itself.

For example, a class can have same class reference in its field (class C { C field; }). All of class types are references in D, so its type size (== definition) is equal to pointer size. So, even if self class type is used in its declaration, it won't cause definition recursion, because compiler can treat the class definition as opaque during semantic analysis of the declaration.

Returning to the template instance case, compiler cannot treat instance definition as opaque. However, to put it another way, compiler cannot detect the "true recursion" until instantiating the template. In other words, we cannot detect template recursion by merely seeing template arguments.

Therefore, I think the check is merely unnecessary. We have to rely on the nest level detector of template instantiations, and circular chain detector of `tinst` during semantic3.
[Refactoring] Remove unnecessary isVarDeclaration() call

`AggregateDeclaration::fields` is typed as an array of `VarDeclaration`. Therefore, assignment its elements to `Dsymbol *` + invocation of `isVarDeclaration` are merely redundant operations.
[Refactoring] Rename makeInvariant to makeImmutable