(Set version to 1.012, as 1.013 isn't in the list yet.) type x; mixin("alias int type;"); All of alias, typedef, enum, struct, class, and a template containing any of the above don't work. Flip the order of the two lines or replace the mixin with its contents and the code compiles.
Created attachment 464 [details] invalidate symbol search cache when adding new symbol the problem in the test case consists of 2 issues. 1. the forward referencing of the type. this is fixed by the patch in issue 102 2. the new symbol not being found in the symbol table. This can be reproduced without triggering bug 102 by static if(is(type)) {} mixin("alias int type;"); type x; test.d(3): Error: identifier 'type' is not defined The problem is that the last symbol being searched in a module is cached to speed up consecutive lookups of the same symbol. When a symbol is added by the mixin, this cached result is not invalidated. The patch adds this invalidation.
patch is against 2.032
The patch doesn't work, even when I disable the cache completely. The reason it doesn't work is because mixins are evaluated at a later stage in the compilation process.
The patch only fixes the name lookup, not the forward reference. As described in comment 1, you'll also need the patch from issue 102 to completely fix the original test case.
As it seems, a patch has crawled into DMD 2.033 that is supposed to fix the second issue described in comment 1. This is line 887 in module.c (in dmd 2.034) else if (searchCacheIdent == ident && searchCacheFlags == flags && searchCacheSymbol) where searchCacheSymbol has been added to allow finding symbols that have been added after the last search. Though this fixes the issue, it has a bad impact on identifier lookup time, especially with a lot of imports, worst with cyclic imports. This is because with this change, not finding an identifier is always expensive, but it is the most common result. This has now shown up with qtd causing the build to lock-up with continuously searching identifiers. I'd still suggest a change along the lines of the patch posted in this issue.
(In reply to comment #5) > As it seems, a patch has crawled into DMD 2.033 that is supposed to fix the > second issue described in comment 1. This is line 887 in module.c (in dmd > 2.034) > > else if (searchCacheIdent == ident && searchCacheFlags == flags && > searchCacheSymbol) > > where searchCacheSymbol has been added to allow finding symbols that have been > added after the last search. > > Though this fixes the issue, it has a bad impact on identifier lookup time, > especially with a lot of imports, worst with cyclic imports. This is because > with this change, not finding an identifier is always expensive, but it is the > most common result. > > This has now shown up with qtd causing the build to lock-up with continuously > searching identifiers. I'd still suggest a change along the lines of the patch > posted in this issue. The applied patch in rev. 205 brought QtD back to life. Thank you.
A related example that fails to compile: enum Y { A, B=mixin(s), C } const string s="4";
The test case in comment 7 was fixed in 2.051 and 1.066. The original test case still doesn't work.
I'm removing the 'patch' keyword, since even though the patches from here and from bug 102 have been applied, the original bug is not fixed.
*** Issue 4226 has been marked as a duplicate of this issue. ***
Change to D2 issue, because D1 is no longer supported.
@RazvanN7 created dlang/dmd pull request #9873 "Fix Issue 1170 - Cannot forward reference a type defined in a MixinStatement" fixing this issue: - Fix Issue 1170 - Cannot forward reference a type defined in a MixinStatement https://github.com/dlang/dmd/pull/9873
dlang/dmd pull request #9873 "Fix Issue 1170 - Cannot forward reference a type defined in a MixinStatement" was merged into master: - 462fdccb04d93b37aebb02643253e281eb7e00e2 by RazvanN7: Fix Issue 1170 and 10739 - Cannot forward reference a type defined in a MixinStatement https://github.com/dlang/dmd/pull/9873