LinqOverCSharp Work Item Rss Feed

Created Issue: Infinite loop in syntax parsing [15436]

vizu — Tue, 15 Dec 2009 08:55:39 GMT

This test data puts the parser in an infinite loop.

class A { void M() { void a1; } }

The keyword "void" is not legal as the type of a local variable, which is correctly detected, but the parsing doesn't move on but reports the same error infinitely.

Created Feature: Resolve interface name in reflected explicitly implemented interface members [14248]

vizu — Thu, 24 Sep 2009 13:55:45 GMT

See eg. MetadataImporterSemanticEntityFactory.CreatePropertyEntity. Interface name not resolved because it's not trivial. (Possible namespaces, type arguments, array dimensions, pointer, etc.) Something similar is needed as the TypeNodeBaseTypeEntityReference but without syntax nodes.

Created Task: Rethink lazy importing of reflected members [14243]

vizu — Thu, 24 Sep 2009 08:34:20 GMT

Members of reflected types are imported in a lazy load fashion to avoid expensive and unnecessary operations.
So the semantic graph visitors will not touch those member nodes.
Can it cause a problem?

Created Feature: Fluent interface for AST and SG

vizu — Thu, 20 Aug 2009 10:13:36 GMT

It would be nice to have a fluent-style interface for AST and SG creation, which also prohibits the creation of ill-structured ASTs and SGs.

Created Issue: Revise TypeNode usage in AST nodes (is NamespaceOrTypeNameNode more appropriate?)

vizu — Wed, 19 Aug 2009 12:39:24 GMT

The spec makes a distinction between "type" and "type-name". Type can be a simple type-name too, but can also be a constructed type like int*[].
Previously all type and type-name instances were represented by TypeOrNamespaceNode. Then I split it into TypeNode (for "type") and NamespaceOrTypeNameNode (for "namespace-or-type-name" and "type-name").
The former TypeOrNamespaceNode became TypeNode, but not all usages were revised whether it is a legitimate usage of TypeNode (ie. the spec uses "type") or it should be changed to NamespaceOrTypeNameNode (ie. the spec uses "type-name" or "namespace-or-type-name").

Created Issue: Break circular dependency between AST and SG

vizu — Mon, 20 Jul 2009 19:29:10 GMT

ISyntaxNode has a List<SemanticEntities> collection, and SemanticEntity has a List<ISyntaxNode> collection.
Is it a problem? If so, then how should we fix this?

Closed Issue: MemberDeclarator not strict enough

vizu — Mon, 06 Jul 2009 13:20:45 GMT

MemberDeclaratorNode and its corresponding rule in the ATG are to generous. Should only allow SimpleName, MemberAccess or ident = Expression.
Comments:

Solved by adding a CreateMemberDeclarator method that checks if the parsed expression is of the correct type.

Created Issue: MemberDeclarator not strict enough

vizu — Tue, 30 Jun 2009 14:11:13 GMT

MemberDeclaratorNode and its corresponding rule in the ATG are to generous. Should only allow SimpleName, MemberAccess or ident = Expression.

Created Issue: Resolve all Coco warnings

vizu — Mon, 29 Jun 2009 09:01:43 GMT

Coco gives a number of warnings (LL1 conflicts and misplaced resolvers). All warnings should be investigated and either eliminated or explicitly marked as safe.

Closed Task: 1 sourcefile = 1 type

vizu — Mon, 29 Jun 2009 08:59:18 GMT

Comments:

Done for the new project CSharpTreeBuilder.

Closed Feature: Test file location via environment variable

vizu — Mon, 15 Jun 2009 09:59:15 GMT

Test file locations are hardcoded const strings. It would be better to get the test source root from an env variable, and hardcode only the relative paths.
Comments:

Done in 34354.
Test file folder can be configured with environment variables 'LOCDrive' and 'LOCPath'.

Created Feature: Test file location via environment variable

vizu — Mon, 11 May 2009 11:49:38 GMT

Test file locations are hardcoded const strings. It would be better to get the test source root from an env variable, and hardcode only the relative paths.

Created Task: 1 sourcefile = 1 type

vizu — Fri, 08 May 2009 09:09:33 GMT

CREATED FEATURE: Handling EndLine and EndPosition

INovak — Mon, 17 Sep 2007 12:30:55 GMT

The LanguageElement class should be able to handle the last position (Line, column and file position) of the related language element.

CREATED ISSUE: Process '#pragma warning'

INovak — Wed, 18 Jul 2007 12:48:12 GMT

Right now the compiler specific #pragma is not precessed. It has two options: '#pragma warning' and '#pragma checksum'. The first option should be processed.

CLOSED ISSUE: #line pragma is not processed.

INovak — Wed, 18 Jul 2007 12:45:40 GMT

The #line pragma should be processed acconding to language specification. Requires refactoring in error handling (how file names and line numbers are handled)

CLOSED ISSUE: #error pragma should be processed.

INovak — Wed, 18 Jul 2007 11:23:18 GMT

The #error pragma should be processed acconding to language specification. Requires refactoring in error handling.

CLOSED ISSUE: #warning pragma should be processed.

INovak — Wed, 18 Jul 2007 11:23:17 GMT

The #warning pragma should be processed acconding to language specification. Requires refactoring in error handling.

CLOSED ISSUE: Pragmas closed with EOF cause syntax error.

INovak — Wed, 18 Jul 2007 09:50:19 GMT

All pragmas that are in the last line of the source code and are not terminated with an end-of-line token (but EOF) cause a syntax error.

Resolution: The scanner has been modified so if an EOF is found, it sends back one end-of-line character before signing the end-of-file.

CREATED ISSUE: Pragmas closed with EOF cause syntax error.

INovak — Wed, 18 Jul 2007 09:36:58 GMT

All pragmas that are in the last line of the source code and are not terminated with an end-of-line token (but EOF) cause a syntax error.