2.3.2.8 release notes

2.3.2.8

  • Issue 1009 - Enhanced the Apex Illegal Assignment code inspection to detect implicit conversions of Date expressions to Datetime expressions. These implicit conversions use GMT for the time zone, likely resulting in unexpected or incorrect Datetime values. Such expressions are flagged as warnings with a quick fix to adapt the Date expressions into more explicit Datetime expressions. In general, Date expressions are adapted as follows:
    Datetime.newInstance(dateExpression, Time.newInstance(0, 0, 0, 0))
    However, Date.today() and System.today() and are converted to Date.now() and System.now() respectively. This check is enabled by default but can be disabled if desired as a configuration setting of the Illegal Assignment inspection.
  • Issue 2626 - Fixed an issue with enumeration of EmailTemplate folder metadata which has two distinct folder metadata types, EmailTemplateFolder and EmailFolder. Only the latter was being enumerated by IC2 previously, so folders of the former type and their contents might have been missing in the metadata subscription editor and bulk metadata management dialog.
  • Issue 2627 - Updated the labels for configuration options Use push/pull instead of deploy/retrieve/delete and Use deploy/retrieve/delete instead of push/pull to be Use source tracking instead of deploy/retrieve/delete and Use deploy/retrieve/delete instead of source tracking respectively to align with recent changes in Salesforce DX terminology.
  • Enhanced the Apex Illegal Assignment code inspection to report invalid casts and impossible/superfluous instanceof checks, particularly those that would result in Operation instanceof is always true/false compile-time errors. Note that the latter are reported as follows:
    • When an instanceof check would result in a compile-time error, it is flagged as an error in the IDE. Note that some of these compile-time errors seem to be incorrect, e.g., the following:
      Account acct = null;
      System.debug(acct instanceof SObject);
      where the last line results in the compile-time error Operation instanceof is always true, but the instanceof expression should actually evaluate to false. I have reported issues of this type to Salesforce as potential/likely Apex compiler bugs, but until they're fixed, IC2 will provide behavioral parity with the compiler to minimize errors that require a (potentially expensive) failed deployment to find.
    • When an instanceof check would compile without errors but always evaluate to false, it is flagged as a warning in the IDE. As above, instances of this are likely due to Apex compiler bugs that I've reported to Salesforce, but while they exist, I prefer to flag errors only when the corresponding code will also result in errors during deployment.
  • Added a new Apex Unnecessary Cast code inspection that flags unnecessary type casts as warnings with a quick fix to remove the casts and, if appropriate, any surrounding parenthesized expressions to simplify the already-sufficiently-typed nested expressions.

    Note that Apex includes several automatic type casting and coercion features that obviate the need for explicit type casts in certain situations, and the rules for these "syntactic sugar" features are neither well-documented nor consistent in behavior. I have tuned and tested the logic for this new inspection against approximately 30 prominent open source Apex projects to help minimize the opportunity for false positives in end user code, but my guess is that there are likely some remaining special-case exceptions that will need to be handled.

    If you're interested in applying this clean-up inspection to your code base, I'd recommend the following:
    1. Run the inspection en masse against your code base using Code | Analyze Code | Run Inspection by Name... | Unnecessary Cast (Salesforce).
    2. From the inspection results, apply the Remove unnecessary cast quick fix to all found instances.
    3. Perform a deployment of those changes, ideally executing unit tests as part of the deployment. If deploying against a shared or "sacred" org, this should be a check-only deployment until the resulting changes have been confirmed sufficiently.
    4. If deployment and/or test failures are reported, please try to extract standalone reproducible examples of the before/after states of the failing code and report them via the public issue tracker. Revert those specific changes. I will use such feedback to fix any issues with the inspection and/or enhance the inspection's special-case exceptions to ensure that these types of necessary casts are not interpreted as unnecessary and flagged for removal.

    This new inspection has been added to the bundled inspection profiles, but if you are using a custom inspection profile that is configured not to add new inspections automatically, you will need to update your custom inspection profile to include it.
  • Other related fixes and improvements.