D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 5184 - throw ClassName.templatedStaticMethod(...) cannot be parsed
Summary: throw ClassName.templatedStaticMethod(...) cannot be parsed
Status: RESOLVED FIXED
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: All Windows
: P2 normal
Assignee: No Owner
URL:
Keywords: patch, rejects-valid
Depends on:
Blocks:
 
Reported: 2010-11-07 01:18 UTC by Kazuhiro Inaba
Modified: 2015-06-09 05:11 UTC (History)
1 user (show)

See Also:


Attachments
A patch to fix the issue (631 bytes, patch)
2011-04-09 02:10 UTC, Kazuhiro Inaba
Details | Diff

Note You need to log in before you can comment on or make changes to this issue.
Description Kazuhiro Inaba 2010-11-07 01:18:51 UTC
The following code doesn't compile (in dmd 2.050 and 1.065), but I think it should.

class Factory
{
	static Exception create(T)(T x)
	{
		return new Exception("whatever");
	}
}

void main()
{
	throw Factory.create(123);
}

Error message is the following:

> test.d(11): Error: type Factory is not an expression

Either one of the changes dissolves the compilation failure:

- Changing the method declaration into a non-template
	create(int x)
- Decomposing the throw statement as
	auto e = Factory.create(123); throw e;

The combination of throw+static+template seems causing a trouble.
Comment 1 Kazuhiro Inaba 2011-04-09 02:10:36 UTC
Created attachment 941 [details]
A patch to fix the issue

What was happening was:

1. Factory.create(123) is desugared into CommaExp: (Factory, Factory.create(123)).
   This is done in CallExp::semantic when the method is static template method.
   I'm not at all sure but is this for keeping side-effects for some cases?

2. In e2ir.c TypeExp::toElem emits the compilation error; it tries to compile
   lhs and rhs into IR, but TypeExp cannot be compiled to IR.

The patch modifies the first point. If the expression is "TYPE . SOMETHING",
the CommaExp insertion is disabled.

FYI, the problematic error is issued only inside ThrowStatement, because
in ThrowStatement::semantic, exp->optimize() is not called.
In, e.g., ReturnStatement::semantic optimizes away the TypeExp before toIR
convertion, so it won't cause any problem. (I don't know the reason why.)