- 14 5月, 2015 1 次提交
-
-
由 Kevin Halverson 提交于
-
- 21 3月, 2015 1 次提交
-
-
由 beep boop 提交于
Now that the comment formatting issue is fixed in the Formatter type, we can run the formatter on the remainder of the VB code base. closes #1424
-
- 28 2月, 2015 1 次提交
-
-
由 Vladimir Reshetnikov 提交于
-
- 13 2月, 2015 2 次提交
-
-
由 Jared Parsons 提交于
There were some issues getting xunit to respect the -notrait option hence we decided to simplify and use ConditionalFact
-
由 Jared Parsons 提交于
This change allows provides the option of running our tests in 64 bit mode. Simply invoke BuildAndTest.proj in the following manner: > msbuild /v:m /m BuildAndTest.proj /p:Test64=true There are a set of tests today that don't run correctly in 64. All have been annotated with the trait > Require32=true We need to push on these to get a clean 64 bit run. But short term this will at least give us protection against regressions.
-
- 28 1月, 2015 1 次提交
-
-
由 pgavlin 提交于
Fix a bug in the adjusted Color Color code that failed to correctly account for instance members on base types. ***NO_CI*** (changeset 1404916)
-
- 25 1月, 2015 1 次提交
-
-
由 pgavlin 提交于
Before this change, Roslyn used a slightly different Color Color rule for Visual Basic than the Dev12 compiler. Where the Dev12 compiler's rules would never result in an unresolvable ambiguity, the Roslyn compiler's could, particularly if the LHS required late binding or had errors. The Color Color rules have been therefore been adjusted to make decisions in the same manner as Dev12 for late-bound cases (where we must be compatible). The new rules are given below. If the base expression of a member access expression is a simple name and binds to a constant, field, property, local variable or parameter whose type has the same name, then the base expression can refer either to the member or the type. This can never result in ambiguity because the members that can be accessed off of either one are the same. In the case that such a base expression binds to an instance member but the binding occurs within a context in which "Me" is not accessible, the expression instead binds to the type (if applicable). If the base expression cannot be successfully disambiguated by the context in which it occurs, it binds to the member. This can occur in particular in late-bound calls or error conditions. ***NO_CI*** (changeset 1403686)
-
- 24 1月, 2015 2 次提交
-
-
由 AlekseyTs 提交于
Ensure that SemanticModel always gets the same bound tree for a Const local initializer regardless in what order statements are bound. ***NO_CI*** (changeset 1401983)
-
由 pgavlin 提交于
As in the original C# implementation of Color Color handling, the Color Color handling in the VB binder originally used lookup to decide the meaning of an ambiguous identifier as a simple name or type name instead of binding. Unfortunately, this is not correct: the meaning of an identifier as outlined in the spec is defined by binding. This caused the compiler to incorrectly fail to recognize Color Color in situations where a simple name or type name lookup is ambiguous but a bind of the same is not. This change replaces the lookups used in Color Color with binds, which brings Roslyn's behavior back in line with Dev12 and the spec in cases that fit such cases. This change is likely to be slightly perf-positive in cases involving a simple name that does not bind to a symbol that qualifies for the Color Color rule: in this case, the old code performed a lookup followed by a bind, whereas the new code simply performs a bind and returns the result. There is likely to be a perf penalty in a true Color Color case, however, as the bound node is larger and the new code is unconditionally binding the type even in the case where the type will not be used (whereas the old code would simply look up the type). ***NO_CI*** (changeset 1401089)
-
- 15 1月, 2015 1 次提交
-
-
由 jaredpar 提交于
-
- 14 1月, 2015 2 次提交
-
-
由 RoslynTeam 提交于
-
由 TomasMatousek 提交于
1) Assigns each member a "member ordinal" - the index in the members array of the containing type. The ordinal is propagated thru lowering rewriters which uses it to make generated names unique. 2) We no longer calculate "overload ordinal" for names of state machine types, we use the member ordinal of the async/iterator method instead. 3) Removes GenerateTempNumber from TypeCompilationState. Combination of method ordinal and other indices is used to make generated names unique: - Display classes use ordinal of the method containing the lambda and closure scope ordinal (unique within a method). Static display class is shared across all non-generic methods of a containing class and thus doesn't need a unique number in name. - Lambda methods include containing method ordinal (unless emitted to a display class whose name already includes it) and lambda ordinal (unique within a method). - The same for fields caching lambdas. - Delegate relaxation stubs and their closures have a separate numbering and are distinguished from regular lambdas/closures, since they are immutable and EnC doesn't need to map them across generations. - Late-bound AddressOf operator oddly creates real closure and is thus not considered a delegate relaxation for the purposes of synthesized naming. - Properties generated to override inherited WithEvent properties are assigned ids in the source order of Handles clauses. In order to guarantee uniqueness of the names added during EnC include generation ordinal in synthesized names wherever we use method ordinal. Generation ordinal 0 (regular build) is omitted - the additional number is only added to names of synthesized members created during EnC compilation. (changeset 1395267)
-
- 07 1月, 2015 1 次提交
-
-
由 pgavlin 提交于
This is consistent with the spec and Dev12. ***NO_CI*** (changeset 1387266)
-
- 24 12月, 2014 1 次提交
-
-
由 wochae 提交于
Porting the recent C# changes to support EnC for VB Async and Iterator. (changeset 1384053)
-
- 29 10月, 2014 1 次提交
-
-
由 VSadov 提交于
This way we can have better performance of invocations while keeping parameter list of delegate.Method backwards compatible. The approach is basically always to emit backing methods into a display class, just that in a case of lambdas not capturing anything, the display classes will not have any fields. Also, when display classes do not have any fields, lambdas of all nongeneric methods in a given class can share the same display class and in fact can share the same singleton instance. ***NO_CI*** (changeset 1359307)
-
- 17 10月, 2014 1 次提交
-
-
由 angocke 提交于
***NO_CI*** (changeset 1356181)
-
- 06 10月, 2014 1 次提交
-
-
由 ADGreen 提交于
Abbreviates the public VB-specific types (e.g. VisualBasicSyntaxTree -> VBSyntaxTree) in accordance with the .NET Class Library Guidelines to avoid overly lengthy names and consistent with the conventions used in other APIs (e.g. VB CodeDom). (changeset 1348499)
-
- 02 10月, 2014 1 次提交
-
-
由 TomasMatousek 提交于
This shelveset implements following changes to metadata reference compiler API in order to remove duplication in the public surface and prevent users from unexpected metadata lifetime issues: 1) MetadataImageReference and MetadataFileReference overlap Currently MetadataImageReference can be constructed from a Stream. MetadataImageReference supports metadata prefetch (reading the blob into memory and close the underlying stream) as well deferred reading (no content is read until the reference is consumed during compilation). MetadataFileReference only supports deferred reading. Lifetime of MetadataFileReference is non-deterministic, the underlying file is locked until no references exist and we GC the metadata. On the other hand, it is possible to construct MetadataImageReference in such a way that allows controlling the underlying resources deterministically. Remove MetadataFileReference, use MetadataImageReference instead. 2) Lifetime management AssemblyMetadata and ModuleMetadata objects hold on resources and implement IDisposable. When using MetadataFileReference constructors and some MetadataImageReference constructors to create references the underlying metadata objects are created implicitly and the user doesn’t have a way to explicitly dispose them. Make MetadataImageReference constructors internal and instead add factory method GetReference on AssemblyMetadata/ModuleMetadata. The usage pattern is: using (var metadata = AssemblyMetadata.CreateFromXxx(…)) { var compilation = CSharpCompilation.Create(syntaxTrees, new[] { metadata.GetReference() }); … } In addition the shelveset makes MetadataImageReference internal and adds the following convenience APIs, that are not the most efficient but are very convenient, easy to discover and safe to use for customers that don’t wanna explicitly manage the lifetime of metadata objects. (changeset 1345987)
-
- 25 9月, 2014 1 次提交
-
-
由 heejaechang 提交于
made compiler error message to not include namespaces in most cases. this should make parsing error message a bit easier. (changeset 1334448)
-
- 10 9月, 2014 3 次提交
-
-
由 Kevin_H 提交于
Delete test associated with "Won't Fix" bug (effort to keep it running would yield net negative returns) (changeset 1331314)
-
由 vladres 提交于
* Fix 879811: Do not suppress ambiguity errors if they are caused be the same nested type imported through several using static directives with different type arguments. * Fix typos in comments, corrupted characters due to incorrect source encoding, remove unnecessary casts, namespace qualifiers, type arguments and using directives. (changeset 1326357)
-
由 wochae 提交于
This is a part of porting C# synthesized refactoring work where the names of long-lived variables follow a naming pattern that allows us to reverse-engineer the SynthesizedLocalKind value from the variable name. Especially in this change, we give a synthesized variable an explicit name based on its SynthesizedLocalKind at emit time, not at local symbol creation time. (changeset 1324862)
-
- 15 8月, 2014 1 次提交
-
-
由 TomasMatousek 提交于
-
- 25 6月, 2014 1 次提交
-
-
由 VSadov 提交于
Changes emit for synthetic methods backing lambda expressions to include dummy "this" parameter to match the number of parameters in delegate "Invoke" method. When implementing static lambdas (those that do not have closures) C# has a choice of emitting an open or a closed delegate. In the latter case we can just enclose null and not use it in the method. It appears that in a case of closed delegate, Invoke dispatch is considerably cheaper - no need to left-shift the arguments to adjust for missing "this". == Example: Consider code like the following Func<int, int, int> adder = (x, y) => x + y; Since the lambda does not need to enclose anything, we can implement it in two ways. • Open delegate implementation (current) public static int Add(int x, int y) { return x + y; } Func<int, int, int> adderOpen = cls1.Add; • Closed delegate implementation (also works and seems better) // does not really need to be an extension when in synthetic code public static int Add(this object dummy, int x, int y) { return x + y; } // enclose null Func<int, int, int> adderClosed = ((object)null).Add; Crude experiments confirm that invoking adderClosed indeed costs noticeably less than adderOpen. (about 30% less in common scenarios like adding two ints) This change adjusts codegen for static lambdas to use closed delegates. (changeset 1285058)
-
- 15 4月, 2014 1 次提交
-
-
由 YingP99 提交于
-
- 19 3月, 2014 1 次提交
-
-
由 Pilchie 提交于
-