Don't require TypeInfo in a minimal runtime if it's not needed by JinShil · Pull Request #7799 · dlang/dmd

JinShil · 2018-01-28T13:29:08Z

This is a followup to the following PRs

Don't generate ModuleInfo if it's not declared in druntime #7395 and Optional ModuleInfo (Part 2): Backend Optimizations #7768 for ModuleInfo
Don't generate exception handling code if Throwable is not declared #7786 for Throwable

It is to TypeInfo what the above PRs were for ModuleInfo and Throwable

With this PR, it is now possible to have the same functionality as -betterC (without the -betterC compiler switch) by simply adding the following minimal runtime for executables...

module object;

private alias extern(C) int function(char[][] args) MainFunc;
private extern (C) int _d_run_main(int argc, char** argv, MainFunc mainFunc)
{
    return mainFunc(null);  // assuming `void main()`
}

... or the following minimal runtime for libraries:

module object;

For libraries it would be nice to not require an empty object.d file, but I'm leaving that for another potential PR. UPDATE: See #7825

Again, this will be of interest to users wishing to incrementally or partially port D to new platforms, users hoping to target resource constrained platforms, and users wishing to use D as a library from other languages without druntime.

dlang-bot · 2018-01-28T13:29:09Z

Thanks for your pull request, @JinShil!

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.

JinShil · 2018-01-28T13:32:47Z

src/dmd/typinf.d

+    {
+        torig.error(Loc.initial, "`TypeInfo` cannot be used with -betterC");
+        fatal();
+    }


This block of code was modified to make it consistent with the following in statementsem.d

dmd/src/dmd/statementsem.d

Lines 3626 to 3636 in ec4534e

if (!global.params.useExceptions)

{

tcs.error("Cannot use try-catch statements with -betterC");

return setError();

}

if (!ClassDeclaration.throwable)

{

tcs.error("Cannot use try-catch statements because `object.Throwable` was not declared");

return setError();

}

Can we have a valid line for the error?

Does this error apply for both explicit and implicit uses of RTTI?

Does this error apply for both explicit and implicit uses of RTTI?

It applies to anything that ends up calling genTypeInfo, which, under the current implementation could be implicit or explicit uses of TypeInfo. For example, trying to do a string concatenation will eventually call runtime hooks like _d_arraycatnTX which takes TypeInfo as one of its arguments. See https://issues.dlang.org/show_bug.cgi?id=18312

IMO all of those runtime hooks should be changed to templates, that don't require TypeInfo, so we shouldn't need TypeInfo for string concatenation as long as the runtime hooks are implemented. That's something I hope to champion after this PR (maybe 1 or 2 more) are merged.

TL;DR: Yes implicit and explicit uses of TypeInfo will trigger the error, but by replacing runtime hooks with templates (later) we may be able to eliminate such errors.

Ok, but I'd still feel better if explicit uses got a file/line location to highlight where you're using RTTI.

By "explicit uses" are you referring to typeid? That's the only case I can think of where TypeInfo is explicitly used, and even then, it's indirect. Please let me know if you have something else in mind.

I think showing the location of implicit uses is even more desirable, as you cannot grep for these as with explicit uses of typeid. That would mean to pass the location of an expression via semanticTypeInfo and getTypeInfoType.

That will probably also be helpful when generating type info more lazily as in #6561

OK, I'll explore this. Marking this as WIP while I try.

wilzbach · 2018-01-28T13:52:19Z

test/compilable/minimal.d

-// ModuleInfo and exception handling code
+// This test ensures an empty main with a struct, built with a minimal runtime,
+// does not generate ModuleInfo or exception handling code, and does not
+// require TypeInfo


Don't you have to modify verify_symbols to check for TypeInfo?

Yeah, best to be thorough. Done.

JinShil · 2018-02-10T04:13:06Z

Ping @WalterBright, @ZombineDev, @ibuclaw... anyone, really.

ibuclaw · 2018-02-11T07:39:26Z

src/dmd/typinf.d

+    {
+        torig.error(Loc.initial, "`TypeInfo` cannot be used with -betterC");
+        fatal();
+    }


Can we have a valid line for the error?

ibuclaw · 2018-02-11T07:41:54Z

src/dmd/typinf.d

+    {
+        torig.error(Loc.initial, "`TypeInfo` cannot be used with -betterC");
+        fatal();
+    }


Does this error apply for both explicit and implicit uses of RTTI?

JinShil · 2018-02-12T20:16:06Z

I add a Loc parameter to genTypeInfo for reporting line numbers in the error messages. This increased the diff, of course.

I also added DDoc header comments to the function signatures I modified, and a couple more tests to increase coverage.

There is somewhat of a drawback to this, however. For example, the following code will produce an error message about TypeInfo when it is not apparent, at all, why TypeInfo is needed.

void test()
{
    string s = "abc"
    s = "(" ~ s ~ ")";  // main.d(8): Error: `object.TypeInfo` was not found
}

That is not actually a problem with this PR, but a general problem with D's ubiquitous use of runtime type information (i.e. TypeInfo) for things that are known at compile-time. As I mentioned previously, I intend to champion an effort replace such uses of TypeInfo with templates, which should actually eliminate all such errors, and produce messages that are more meaningful.

cc @ibuclaw @rainers

rainers

Apart from nits LGTM

rainers · 2018-02-12T21:14:56Z

src/dmd/e2ir.d

                    // This is a hack so we can call postblits on const/immutable objects.
-                    elem *eti = getTypeInfo(tb.unSharedOf().mutableOf(), irs);
+                    AggregateDeclaration ad = cast(AggregateDeclaration)tb;
+                    elem *eti = getTypeInfo(ad.loc, tb.unSharedOf().mutableOf(), irs);


This location is the one of the aggregate declaration, not the using expression. For completeness, setArray should probably receive the expression to forward it here.

Done. Thanks for the help!

rainers · 2018-02-12T21:16:44Z

src/dmd/typinf.d

    if (!Type.dtypeinfo)
    {
-        torig.error(Loc.initial, "TypeInfo not found. object.d may be incorrectly installed or corrupt, compile with -v switch");
+        torig.error(loc, "`object.TypeInfo` was not found");


Maybe add "but implicitly used" to the error message.

WalterBright · 2018-05-24T21:17:57Z

This produced a regression https://issues.dlang.org/show_bug.cgi?id=18905

JinShil commented Jan 28, 2018

View reviewed changes

wilzbach reviewed Jan 28, 2018

View reviewed changes

This was referenced Feb 1, 2018

Don't require object.d for -lib if code does not utilize runtime features #7825

Closed

Add changelog for minimal runtime implementation PRs #7829

Closed

jacob-carlborg approved these changes Feb 10, 2018

View reviewed changes

ibuclaw requested changes Feb 11, 2018

View reviewed changes

JinShil added the Review:WIP Work In Progress - not ready for review or pulling label Feb 11, 2018

rainers reviewed Feb 12, 2018

View reviewed changes

JinShil removed the Review:WIP Work In Progress - not ready for review or pulling label Feb 13, 2018

Don't require TypeInfo in a minimal runtime if it's not needed

8d1f1a1

rainers approved these changes Feb 13, 2018

View reviewed changes

rainers added the Merge:auto-merge label Feb 13, 2018

dlang-bot merged commit 97e6d51 into dlang:master Feb 13, 2018

JinShil mentioned this pull request Feb 13, 2018

Add changelog for minimal runtime implementation PRs #7887

Merged

wilzbach mentioned this pull request Mar 18, 2018

Fix issue 18242 - Warn if object.Exception is missing #8050

Merged

This was referenced Apr 24, 2018

Add ability to use interfaces and classes without the runtime if they only contain static members #8204

Merged

Add ability to use enums without the runtime #8205

Merged

JinShil deleted the optional_typeinfo branch April 24, 2018 10:25

n8sh mentioned this pull request May 25, 2018

Fix issue 17968 - Use typeid(Object) instead of typeid(T) to avoid pulling in unused symbols #8222

Merged

JinShil mentioned this pull request May 18, 2019

Add -revert=noautoimports to begin transitioning to a pay-as-you-go opt-in langauge #9814

Closed

JinShil mentioned this pull request Aug 26, 2019

Move hard-coded logic to generate C main out of the compiler and into druntime #10351

Merged

	if (!global.params.useExceptions)
	{
	tcs.error("Cannot use try-catch statements with -betterC");
	return setError();
	}

	if (!ClassDeclaration.throwable)
	{
	tcs.error("Cannot use try-catch statements because `object.Throwable` was not declared");
	return setError();
	}

Uh oh!

Conversation

JinShil commented Jan 28, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

dlang-bot commented Jan 28, 2018

Bugzilla references

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JinShil commented Feb 10, 2018

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JinShil commented Feb 12, 2018 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rainers left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

WalterBright commented May 24, 2018

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

7 participants

JinShil commented Jan 28, 2018 •

edited

Loading

JinShil commented Feb 12, 2018 •

edited

Loading