- 17 11月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 16 11月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 03 11月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 01 11月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 08 10月, 2016 2 次提交
-
-
由 CyrusNajmabadi 提交于
-
由 CyrusNajmabadi 提交于
-
- 24 8月, 2016 1 次提交
-
-
由 Balaji Krishnan 提交于
.. Prefer Intrinsic Type codestyle.
-
- 21 7月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 24 6月, 2016 1 次提交
-
-
由 gafter 提交于
-
- 19 6月, 2016 1 次提交
-
-
由 Jared Parsons 提交于
-
- 16 6月, 2016 1 次提交
-
-
由 CyrusNajmabadi 提交于
-
- 26 5月, 2016 1 次提交
-
-
由 Brett V. Forsgren 提交于
-
- 07 5月, 2016 1 次提交
-
-
由 Julien 提交于
-
- 06 4月, 2016 1 次提交
-
-
由 Balaji Krishnan 提交于
-
- 29 2月, 2016 1 次提交
-
-
由 Balaji Krishnan 提交于
If the preference is set to "use explicit type for built-in type" and if the code is non-compliant (uses var), then we need to flag this case and offer a fix. Basically, this adds to my definition of IsInIntrinsicContext. It is now either that the declaration has a predefined type or the declaration type is inferred and the inferred type is an intrinsic type. For the purposes of this feature, we also consider string and object to be built-in types, in addition to the actual intrinsic types provided by the compiler.
-
- 26 2月, 2016 3 次提交
-
-
由 Balaji Krishnan 提交于
These tests were testing that replacement to var works where type is apparent. but they also had another rule that said prefer built-in types. so i update these tests to not use built-in types and replace them with their framework counterparts. That way we're now clearly testing if the fix works where type is apparent.
-
由 Balaji Krishnan 提交于
The user option gets style preference for built-in types but the implementation checked only for built-in types used _with_ literals on the right hand side. I guess I had two different choices in mind - for built in types overall, or where we use literals in the right hand side and implemented half of both. Anyway, this clears that up - the option gets the preference for built-in types and the implementation checks for predefined types (not literals alone).
-
由 Balaji Krishnan 提交于
Implement a fix all provider for `Prefer Implicit / Explicit type` code style. We simply use the default batchfixer here to fix all nodes which don't comply with the user settings. Notes: 1. we do not differentiate between Notification styles when fixing all non-compliant nodes. i.e., say 2 different locations violate the user preference, but one has notification level 'warn', while the other has notification level 'info', invoking fix-all here will fix both the nodes. In other words, fix-all doesn't differentiate between two nodes that have different notification levels or severity levels. 2. this is a given, but still noting it down. we do differentiate between nodes with different style preferences. For e.g: say the user prefers explicit type for built-in types but implicit type everywhere else, the batch fixer would fix only nodes that do not comply with the preferences. 3. the current implementation fixes all occurrences of the same kind of violation - using explicit type when implicit is preferred or vice-versa, however, it does not fix all violations between kinds (implicit -> explicit, explicit -> implicit). This is because my current implementation has a different diagnostic for each kind of violation. Having a single diagnostic and fixer would have been better for this. I'll add this to my todo list.
-
- 25 2月, 2016 1 次提交
-
-
由 Balaji Krishnan 提交于
Most fixes are about code style. Major changes are in: 1. the algorithm to determine if type is apparent in creation or conversion methods. 2. option serialization/deserialization.
-
- 24 2月, 2016 8 次提交
-
-
由 Balaji Krishnan 提交于
... with notification levels and also test notification levels.
-
由 Balaji Krishnan 提交于
These are additive minor changes to code naming, styling, documentation, tests and such. No major functional changes.
-
由 Balaji Krishnan 提交于
-
由 Balaji Krishnan 提交于
We now detect a conversion, if any, do not suggest use var if it changes semantics, as it would for some implicit conversions. We also recognize type conversion patterns for IsTypeApparent(). For e.g., we recognize static helpers like `int.Parse`, `Convert.ToString()` and instance method `IConvertible.ToChar` etc.
-
由 Balaji Krishnan 提交于
Changed the UI from combinations of radio buttons and check boxes to use just checkboxes. Also changed how the partitions of `use var` space was logically represented. We now present 3 options - use var on intrinsic types, use var where apparent, use var in rest of the places. If all 3 are checked, we universally use var everywhere. If only one or a combination less than 3 are selected, we use var only in those places. An unchecked option means, user prefers explicit typing for that scenario. Not yet implemented : enforcement levels of the fix, fancy previews that show results for a combination of choices, integrating the options into code generation service.
-
由 Balaji Krishnan 提交于
Refactor UseImplicitTyping and UseExplicitTyping Analyzers to use an abstract base class and share common functionalities. Also wire up options into unit tests.
-
由 Balaji Krishnan 提交于
Add an analyzer and fixer for using explicit type over var for C#. Plus, unit tests.
-
由 Balaji Krishnan 提交于
shelving, edit this commit later.
-