-Major tasks:
-------------
+TODO:
- Properties and 17.6.3: Finish it.
+ 1. Create a "partial" emit context for each TypeContainer..
- Implement base indexer access.
+ 2. EmitContext should be partially constructed. No IL Generator.
-MethodGroupExpr
+ interface_type review.
- These guys should only appear as part of an Invocation, so we
- probably can afford to have a special callback:
+ parameter_array, line 952: `note: must be a single dimension array type'. Validate this
- Expression.ResolveAllowMemberGroups
+Dead Code Elimination bugs:
+---------------------------
- This is only called by Invocation (or anyone that consumes
- MethodGroupExprs)
+ I should also resolve all the children expressions in Switch, Fixed, Using.
- And the regular DoResolve and DoResolveLValue do emit the error
- 654 `Method referenced without argument list'.
+Major tasks:
+------------
- Otherwise, a resolution will return a MethodGroupExpr which is
- not guaranteed to have set its `Expression.Type' to a non-null
- value.
+ Pinned and volatile require type modifiers that can not be encoded
+ with Reflection.Emit.
-AddressOf
- Needs an extra argument: `set' or `read', this will help
- to track usage errors in variables (since AddressOf does not
- really know what is it being used for, it could be either)
+ Properties and 17.6.3: Finish it.
+
+ Implement base indexer access.
+readonly variables and ref/out
+
BUGS
----
-* readonly fields behave differently for "fetching" their addresses.
+* We suck at reporting what turns out to be error -6. Use the standard error message
+ instead.
- Look at DoubleConstant.AsString: a copy is made into a local
- variable
+* Explicit indexer implementation is missing.
* Check for Final when overriding, if the parent is Final, then we cant
allow an override.
-* Add test case for destructors
-
-* Do not declare a .property on things that are just implementations, that
- comes from the parent, just do the method.
-
-* Currently the code path for 108/109 reporting is not being ran for methods
- as we need to compare method signatures. But since we retrieve the expensive
- method arguments in the method, we probably should do 108/109 processing there.
-
-* Emit warning on hiding members without NEW not only in members.
-
-* Implement visibility.
-
-* Adding variables.
-
- We do add variables in a number of places, and this is erroneous:
-
- void a (int b)
- {
- int b;
- }
-
- Also:
-
- void a (int b)
- {
- foreach (int b ...)
- ;
- }
-
-* Visibility
-
- I am not reporting errors on visibility yet.
-
* Interface indexers
I have not figured out why the Microsoft version puts an
Explanation: The reason for the `instance' attribute on
indexers is that indexers only apply to instances
-* Arrays
-
- We need to make sure at *compile time* that the arguments in
- the expression list of an array creation are always positive.
-
-* Implement dead code elimination in statement.cs
-
- It is pretty simple to implement dead code elimination in
- if/do/while
-
-* Indexer bugs:
-
- the following wont work:
-
- x [0] = x [1] = N
-
- if x has indexers, the value of x [N] set is set to void. This needs to be
- fixed.
-
-* Array declarations
-
- Multi-dim arrays are declared as [,] instead of [0..,0..]
-
* Break/Continue statements
A finally block should reset the InLoop/LoopBegin/LoopEnd, as
PENDING TASKS
-------------
-* Unsafe contexts:
- Done: class, struct, interface
- Everywhere where we lookup a type, we should test for unsafe pointers.
-
+* IMprove error handling here:
+
+ public static Process ()
+
+ THat assumes that it is a constructor, check if its the same name
+ as the class, if not report a different error than the one we use now.
+
+* Merge test 89 and test-34
+
+* Revisit
+
+ Primary-expression, as it has now been split into
+ non-array-creation-expression and array-creation-expression.
* Static flow analysis
Handle modreq from public apis.
+* Emit `pinned' for pinned local variables.
+
+ Both `modreq' and pinned will require special hacks in the compiler.
+
+* Make sure that we are pinning the right variable
+
+* Maybe track event usage? Currently I am not tracking these, although they
+ are fields.
+
+* Merge tree.cs, rootcontext.cs
+
OPTIMIZATIONS
-------------
-* Emitcontext
+* There is too much unshared code between MemberAccess.Resolve and SimpleName
+ resolve.
+
+* User Defined Conversions is doing way too many calls to do union sets that are not needed
- Do we really need to instanciate this variable all the time?
+* Add test case for destructors
- It could be static for all we care, and just use it for making
- sure that there are no recursive invocations on it.
+* Places that use `Ldelema' are basically places where I will be
+ initializing a value type. I could apply an optimization to
+ disable the implicit local temporary from being created (by using
+ the method in New).
-* Static-ization
+* Dropping TypeContainer as an argument to EmitContext
- Since AppDomain exists, maybe we can get rid of all the stuff
- that is part of the `compiler instance' and just use globals
- everywhere.
+ My theory is that I can get rid of the TypeBuilder completely from
+ the EmitContext, and have typecasts where it is used (from
+ DeclSpace to where it matters).
+ The only pending problem is that the code that implements Aliases
+ is on TypeContainer, and probably should go in DeclSpace.
-* Constructors
+* Casts need to trigger a name resolution against types only.
- Currently it calls the parent constructor before initializing fields.
- It should do it the other way around.
+ currently we use a secret hand shake, probably we should use
+ a differen path, and only expressions (memberaccess, simplename)
+ would participate in this protocol.
-* Use of EmitBranchable
+* Use of local temporary in UnaryMutator
- Currently I use brfalse/brtrue in the code for statements, instead of
- using the EmitBranchable function that lives in Binary
+ We should get rid of the Localtemporary there for some cases
+
+* Emitcontext
+
+ Do we really need to instanciate this variable all the time?
+
+ It could be static for all we care, and just use it for making
+ sure that there are no recursive invocations on it.
* ConvertImplicit
Write tests for the various reference conversions. We have
test for all the numeric conversions.
-* Remove the tree dumper, cleanup `public readonly'
-
- And make all the stuff which is `public readonly' be private unless
- required.
-
* Optimizations
In Indexers and Properties, probably support an EmitWithDup
in the stack, so that later a Store can be emitted using that
this pointer (consider Property++ or Indexer++)
-
* Optimizations: variable allocation.
When local variables of a type are required, we should request
* Add a cache for the various GetArrayMethod operations.
-* Optimization:
-
- Do not use StatementCollections, use ArrayLists of Statements,
- and then "copy" it out to arrays. Then reuse the existing
- Statement structures.
-
* TypeManager.FindMembers:
Instead of having hundreds of builder_to_blah hash table, have
a single one that maps a TypeBuilder `t' to a set of classes
that implement an interface that supports FindMembers.
+* MakeUnionSet Callers
+
+ If the types are the same, there is no need to compute the unionset,
+ we can just use the list from one of the types.
+
+* Factor all the FindMembers in all the FindMembers providers.
+
+* Factor the lookup code for class declarations an interfaces
+ (interface.cs:GetInterfaceByName)
+
RECOMMENDATIONS
---------------
Not sure that this grammar is correct, we might have to
resolve this during semantic analysis.
+* Idea
-* Try/Catch
-
- Investigate what is the right value to return from `Emit' in
- there (ie, for the `all code paths return')
-
-
-* Optimizations
-
- Only create one `This' instance per class, and reuse it.
-
- Maybe keep a pool of constants/literals (zero, 1)?
-
-************
-Potential bug:
-
- We would need to decode the shortname before we lookup members?
-
- Maybe not.
-
-interface I {
- void A ();
-}
-
-class X : I {
- void I.A ();
-}
+ MethodGroupExpr
-class Y : X, I {
- void I.A () {}
-}
+ These guys should only appear as part of an Invocation, so we
+ probably can afford to have a special callback:
+ Expression.ResolveAllowMemberGroups
+ This is only called by Invocation (or anyone that consumes
+ MethodGroupExprs)
-*************
+ And the regular DoResolve and DoResolveLValue do emit the error
+ 654 `Method referenced without argument list'.
+ Otherwise, a resolution will return a MethodGroupExpr which is
+ not guaranteed to have set its `Expression.Type' to a non-null
+ value.