Correct types for EditableLists containing Missing items

For example:

• list(,,$c) contains two Missing items
• \Foo\bar() starts with a Missing item with a trailing separator

This changes the types of these members to EditableList<?T> where T is the type of the non-missing items.

In cases where this change introduces type errors, there was previously a risk of runtime exceptions.

Support for HHVM/Hack 3.28, more migrations, as-you-type linting, other improvements

This release supports (and requires) HHVM 3.28

New Features

• add migration to convert PHP stdlib to the HSL
• add add-you-type linting in supported editors
• better diff previews for auto-fixing linters when linting from CLI
• all lint autofixes are now available within supported editors; previously, all lint errors were exposed, but only AST-based lint errors could be fixed within editors

API Changes

• EditableList is now EditableList<T as EditableNode>
• methods that return A|B|Missing now return ?EditableNode; this is to increase consistency, as A|Missing returns ?A
• getFile() now returns a File object, including both a path and content. Linters must operate on the content exposed here for as-you-type linting to work correctly
• fixLintErrors() has been removed, replaced with getFixedFile(); getFixedFile() must not edit the file on disk, but should return a new File object with modification applied
• getPrettyTextforNode() no longer takes a $context parameter; this is rarely used, and requires major usability compromises to the rest of the API. Implementations should store context themselves, or re-calculate it here.
• FixableLintError has been removed: any LintError is fixable if the linter is an AutoFixingLinter
• LSPAutoFixingLinter has been removed; all AutoFixingLinters are now fixable via LSP; this is built on top of getFixedFile() and getTitleForFix()
• Merged BaseASTLintError and ASTLintError into ASTLintError: this distinction was to provide a simpler API for common cases, however the removal of FixableLintError and $context removed all differences.

Other Changes

• removed --io-log-prefix option; the situations where it was useful are better served by in-editor logging, or using a wrapper along the lines of tee stdin.log | path/to/real/hhast-lint "$@" 2>stderr.log | tee stdout.log, as the IO logs only contain output that goes through certain abstractions, rather than all process output.
• added HHAST_LSP_DEBUG environment variable, which prints various state changes to stderr

Bugfix release: false positives for UnusedUseStatement linter

This release fixes a bug in the UnusedUseStatement linter for use type and use statements:

<?hh // strict

// earlier versions of HHAST would incorrectly report `GenericParent` as unused
use type Foo\GenericParent;

class Foo<T> extends GenericParent<T> {
}

This release also includes more complete CSS for the hhast-inspect developer tool.

Improved LSP compatibility

When running in LSP (language server) mode, prior releases still run using the current working directory as the project root; most environments set the working directory to the project root, but this isn't guaranteed by the specification, and isn't done by all implementations.

LSP support, additional linters, `expect()` migration

LSP Support

hhast-lint's LSP mode is now supported, providing IDE integration for lint errors and auto fixes.

LSP support requires HHVM 3.27.1 or later for stability.

Atom IDE

Install the atom-ide-ui and ide-hhast packages.

Nuclide

Install the ide-hhast package.

Visual Studio Code

Install vscode-hack v1.0 or above:

Implementing in other editors

Execute hhast-lint --mode lsp --from your-editor-name-here.

initializationOptions.lintMode can be set to 'whole-project' or 'open-files'; whole-project is the default.

HHAST does not replace hh_client lsp; editors/plugins should be configured to use both.

New Linters

• Add auto-fixing license header linter: if a .LICENSE_HEADER.hh.txt is present, it must be present as a comment in all files in the directory or recursive subdirectories
• Add auto-fixing linter banning use statements with a leading backslash (the backslash does not affect the meaning)
• Add auto-fixing linter banning unused parameters, unless they start with an underscore (e.g. $_)
• Add auto-fixing linter banning unused use clauses

Linter Changes

• CamelCasedMethodsUnderscoredFunctionsLinter now requires that methods are lowerCamelCase
• UseStatementWithAsLinter no longer suggests removing the 'as' as a fix; this almost always introduces many errors.

New Migration

Added bin/hhast-migrate --assert-to-expect to migrate to fbexpect.

New linters, improved performance, additional experimental output formats

This release:

• adds an experimental --mode argument to hhast-lint, supporting JSON and VSCode Language Server Protocol
• Removes --perf in favor of --xhprof
• adds a linter banning use statements without use type, use namespace, use function, use constant etc
• adds a non-default linter requiring <?hh // strict. This can be suppressed for specific files via hhast_lint.json
• handles non-UTF8 source files
• improved performance: HHAST takes approximately 25% of the time to lint itself that it did in 3.27.0

Support for HHVM/Hack 3.27, new linters, developer tools

This release:

• supports additions to the AST in 3.27
• fixes the error messages for the string interpolation linter
• adds a linter for async function naming conventions
• adds a linter to ban basic assignment in function parameters (foo($bar = 'baz');)
• adds an 'inspect' developer tool to interactively examine the AST of a file
• adds an option to disable all linters for specific patterns

Support and require HHVM 3.26, relicense to MIT, experimental support for PHP

This release:

• is available under the MIT license
• adds support for - and requires - HHVM 3.26
• switches version numbering scheme to match HHVM
• has experimental support for PHP code
• adds the IComment marker interface to identify comment nodes
• improves detection of color support and interactive consoles in the CLI utilities

3.26 Requirement

This release of HHAST requires hh_parse from HHVM 3.26; as hh_parse is usually distributed with HHVM itself, HHVM 3.26 has been marked as a requirement in composer.json - however, if you deploy hh_parse separately, you can update independently.

Versioning and lifecycle

HHAST exposes Hack's AST - so, when changes are made to Hack's AST, HHAST itself must change. As such, it is likely that a new version of HHAST will be needed for each HHVM release. Because of that, we've decided to follow HHVM's version numbers for clarity.

The major and minor versions (3.26) will match the minimum version of HHVM required; the revision (.0) is independent for the HHAST.

For bugfixes and security updates, HHAST will follow HHVM's support lifecycle.

Better profiling support, and support for experimental 3.25 typechecker features

• adds a --xhprof option to both hhast-lint and hhast-migrate, which dumps detailed profiling information
• supports experimental typechecker features that will be announced with HHVM 3.25

Initial stable release; performance improvements, additional migrations

Today we're releasing version 1.0, as HHAST is now in regular use at several companies, and the codebase has been largely stable since v0.4, which was released in November.

This release:

• significantly improves the performance of typechecker-based migrations, such as the call-time-pass-by-reference migration
• supports the safe_array, safe_vector_array, and experimental no_fallback_in_namespaces (available in nightly builds) typechecker options
• adds a migration for the no_fallback_in_namespaces option
• adds a generic 'add-fixmes' migration, which adds HH_FIXME comments as required; this is a last resort migration and should be used rarely

Lifecycle

• 1.x releases will be supported throughout the lifecycle of HHVM 3.24, and will continue to target HHVM 3.24.
• when HHVM's AST changes, 1.x will be forked from master, and master + 2.x will target future releases of HHVM
• once 1.x diverges from master, any major changes (e.g. new features, performance improvements) should be made against master, then once committed, if desired, also landed to the 1.x branch