New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix right this check #1687
Fix right this check #1687
Conversation
Requires: |
It seems like this pull is going to break code. |
Yes, very slightly code will be broken. Because they were invalid but accidentally had been accepted. |
This is a perfect time to introduce a file with a list of language changes for the upcoming version, so we're reminded to add this language change to the changelog before release. |
@@ -764,6 +764,7 @@ elem *setArray(elem *eptr, elem *edim, Type *tb, elem *evalue, IRState *irs, int | |||
|
|||
elem *Expression::toElem(IRState *irs) | |||
{ | |||
printf("[%s] %s ", loc.toChars(), Token::toChars(op)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Debug printf
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We never come here in normal, because dmd will assert(0) after that immediately. This is useful in order to know quickly the place where is actually broken.
Is there any chance you can move both the checking and the resolution out of e2ir? Otherwise getrightthis & friend get duplicated for every backend. |
@yebblies That would be a challenge for the future. We should to advance it one step by step. |
@AndrejMitrovic I agree to do it. |
Shouldn't |
@AndrejMitrovic In the future, we need to remove all 'right this' check from glue layer. To do it, adding tests for code generation is necessary. |
Dsymbol *p = sc->parent; | ||
while (p && p->isTemplateMixin()) | ||
p = p->parent; | ||
FuncDeclaration *fdthis = p ? p->isFuncDeclaration(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, now it's still missing the : NULL
else part.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, no! Thanks very much for your mention. Fixed again.
I'm not really positive about the implicit typeof and the error when calling static functions on member variables. struct Foo
{
static struct Bar
{
static int get() { return 0; }
}
Bar bar;
alias bar this;
}
void test8169()
{
// allowed cases that do 'use' Foo.bar without this
static assert(Foo.get() == 0); // typeof(Foo.bar).get()
static assert(typeof(Foo.bar).get() == 0); // typeof(Foo.bar).get()
static assert(Foo.bar.offsetof == 0); // Foo.bar.offsetof
// this is now an error, but it used to work
static assert(Foo.bar.get() == 0); // Foo.bar.get()
} |
@dawgfoto Hmm, to keep current behavior is not impossible. It requires a little more work in CallExp and DotVarExp. |
Updated for @dawgfoto 's review point. |
And, recent Phobos change had shown the incompleteness of my change. To fix the problem, I added one more commit. |
… inside member function Use ThisExp instead of VarExp to avoid interpretation on template arguments.
And, distinguish typeof(Type.var) and typeof({ auto x = Type.var; }) by sc->intypeof == 1 or 2.
Additional fix for Issue 3775 - Segfault(cast.c): casting no-parameter template function using property syntax Allow using Type.templatefunc as a property
…iasthis).member And, add some test cases for 'alias this'.
…vents compilation in inner function
Add test cases for accessing 'this' from constraint and DeclDefs scope
|
(This change is based on #1406)
Currently, dmd front-end does not detect incorrect field access that has no valid 'this' context. Such invalid expression will be detected in glue layer later.
This change fixes the issue. The call of
resolveProperties
is good place to check it.Some "symbol/type related" expressions, e.g.
S.val.offsetof
,S.val.init
, are still valid after this change.A symbol access through "alias this" is treated specially. If
Type.member
is implicitly translated toType.aliasthis.member
, it is further translated totypeof(Type.aliasthis).member
.This change additionally fixes:
Issue 1680 - static struct constructor overloaded with method prevents compilation in inner function