Skip to content

[WIP] Resolve TypeInfo variables after semantic #4654

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

Merged
merged 1 commit into from
May 18, 2015
Merged

Conversation

yebblies
Copy link
Member

Only resolve the type during semantic, and leave all expressions as typeid(xxx). Theoretically this should allow a clean way to ban access to typeinfo at runtime, while still allowing usage during ctfe.

@jpf91

@yebblies yebblies force-pushed the typeid branch 3 times, most recently from d5cb9c6 to b7fe25d Compare May 15, 2015 17:35
@jpf91
Copy link
Contributor

jpf91 commented May 16, 2015

Great idea, thanks! I'll update D-Programming-GDC/gdc#100 later today.

eg alias X = typeof(typeid(x).name); should work even on a system that has no typeinfo at runtime.

Can you give an example why/how this is necessary? Minimal runtimes right now implement TypeInfo as empty classes. For this to work we really need valid, full TypeInfo declarations. It could also be kinda strange if code like this doesn't work:

static if(is(typeof(typeid(a).name)))
{
    auto b = typeid(a).name;
}

@yebblies
Copy link
Member Author

Ok, I guess it's more that there's existing code in druntime that depends on finding the members, so the type must be valid if it's used. Otherwise you'll get 'declaration not found' errors instead of 'cannot use typeinfo' errors. Maybe this is acceptable.

@jpf91
Copy link
Contributor

jpf91 commented May 16, 2015

Yes I think that's acceptable. Looks like we don't have to do anything special about this: If the runtime doesn't provide the declarations and somebody uses typeof(typeid(x).name); they'll get the declaration not found error. If the runtime provides the declarations that code should (and will) work with -fno-rtti.

@yebblies yebblies force-pushed the typeid branch 5 times, most recently from f1421bf to 31d665c Compare May 17, 2015 13:05
@yebblies
Copy link
Member Author

Passing now.

@@ -32,6 +32,7 @@
#include "ctfe.h"
#include "arraytypes.h"
#include "visitor.h"
#include "template.h"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Maybe this is unnecessary.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's for isType.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, thanks.

9rnsr added a commit that referenced this pull request May 18, 2015
Resolve TypeInfo variables after semantic
@9rnsr 9rnsr merged commit 7fa9cd9 into dlang:master May 18, 2015
@yebblies yebblies deleted the typeid branch May 18, 2015 14:56
@timotheecour
Copy link
Contributor

this caused regression 1418:
see digger output here: https://issues.dlang.org/show_bug.cgi?id=14814

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants