hhvm/hack-codegen

Library to programatically generate Hack code and write it to signed files

hack-codegen's Issues

normalize on start vs begin

Add addParameters() function

Look through for setFoo where addFoo could be more consistent

https://www.facebook.com/profile.php?id=100009577249521&fref=ts

Fix fixmes for variadics

/* HH_FIXME[4033] variadic params with type constraints are not supported */

Given that 3.12 support has been dropoped, these can all be cleaned up

Add unit test for exporting collection objects from collection exporters

In particular, make sure they're exported as eg \HH\Vector or Vector, not HH\Vector - and look at HackBuilder::varExport

setExtends() should take a sprintf-style pattern for consistency

Make `HackBuilderValues::set()` and `::immSet()` require an `T as arraykey`

As these are required for sets, should be required for the renderers.

Add hackfmt formatter

Move formatter to HackCodegenConfig

Rename 'annotations' to 'attributes'

'Attributes' is how they are referred to by the HHVM docs, reflection, and the typechecker

Add support for pseudomain code

Required to generate scripts

Remaining documentation

• CodegenClassBase
• CodegenEnum
• CodegenWithInterfaces
• CodegenInterface
• CodegenTrait
• CodegenClass
• CodegenType
• CodegenShape

Add renderer param to addReturn

It's inconsistent. Small breaking change, but seems worthwhile.

Provide/document a way to override HackCodegenConfig that doesn't involve modifying the source code

forking + modifying is not a reasonable approach; not compatible with composer, and makes merging in upstream fixes harder.

addCase should take HackBuilderValues

rename member variables to properties

Migrate to dict/keyset/vec

Not sure if this'll be in v3.0 or not - this depends on the state of their support in HHVM at the time.

Remove LegacyHelpers

These don't need to stay around for 2.0 - they're only still there because I've not had time to update the unit tests yet

Support custom export functions for collection values

I have an ImmMap<string, classname<T>>; it would be useful to be able to specify that the values should be exported by $x ==> "\\".$x.'::class' directly, especially when nested (related: #12)

Comments on CodegenImplementsInterface and CodegenUsesTrait are unsafe format strings

CodegenClassBase::addAbstractConst() doesn't allow specifying a type

Document major changes

Highlights:

• no global config object
• container definitions are nestable
• container order is preserved
• removed behavior where many methods would sometimes interpret the first arg as a plain string, sometimes a format string. The old function name always takes a plain string, 'f' suffix takes a format string, with typechecker validation - eg addReturn('plainstring') and addReturnf('formatstring', ...')
• use PHPUnit instead of custom framework

Full list: v1.1.4...master

addAssignment doesn't support assigning to static properties

HackBuilder->assertIsVariable checks that the passed in variable starts with a $, which means you can't use it to assign to static:: or self::

Replication:

$cgf->codegenHackBuilder()
  ->addAssignment('static::$foo', 'Bar', HackBuilderValues::export())
  ->getCode();

Expected result:

static::$foo = 'Bar';

Actual result:

Fatal error: Uncaught exception 'HH\InvariantException' with message 'Expecting a variable name, but "static::$foo" is not valid.'

Can't scroll at low resolution (eg mobile browsers)

Rewrite CodegenClassBase::setGenericsDecl()

Only supports 'as' constraints

Make CodegenClassBase::addTypeConst take a CodegenType

useNamespace+useClass => useNamespace+useType, generate new syntax

Add lambda key/value renders

facebook

live any one

Add classname renderer

Remove addArrayWithKeysAndArrayListValues

given nested value type definitions are now supported, this is unneeded and makes the API more verbose.

Facebookism: directories created mode 0777

https://github.com/facebook/hack-codegen/blob/master/src/CodegenFile.php#L413

This makes sense if running in the context of the webserver, but is bad for normal cases. This definitely shouldn't be the default.

Make CodegenShape support nested definitions

Support user-provided Attributes

eg $class_builder->addAttribute('MockClass')->addAttribute('CodeGen', 'MyCodeGenScript');

Related: #19

inconsistency: CodegenBaseClass::setHasManualDeclarations() vs setHasManualMethodSection()

Will probably rename setHasManualDeclarations() to setHasManualDeclarationSection()

Figure out what to do for addShape(), remove addArrayKeysAndValues()

Iterator<T> should generally be Traversable<T>

Add clobber option to HackCodegenConfig + interfaces

Add utility scripts to verify signed sources

Probably two:

• hack-codegen-verify-signature.php $file1 [$file2 [ $file3 ...: error if files don't have a valid signature
• hack-codegen-verify-if-signed.php $file1 [$file2 [ $file3...: allow unsigned files, but not files with invalid signatures

Put these in vendor/bin/ when installed via composer, and suggest using them for commit hooks in the documentation.

setUserAttribute should take a hackvaluerenderer

Move setIsOverride from functionbase to methods

Support nested HackBuilderValues definitions

For example, I have an ImmMap<string, ImmMap<string, classname<T>>; I'd like to codegen the same. addImmMap() on that gives me ImmMap<string, ImmMap<string, string>>.

I can work around this by codegen'ing separate locals for each variable as immaps with literal values after mapping ($value ==> "\\".$value.'::class'), then creating the outer ImmMap from these locals also with literal values. It would be good not to have this intermediate step.

Add support for shebang lines

Would be nice for generating scripts

README.md example needs to be updated for namespaces

Doesn't appear to support generating namespaced code

Probably belongs on a per-file scope.

Add way to set class constants

just a test

Document usage scenarios

Outside of Facebook, by default:

• the typechecker is automatically ran on page requests
• a typechecker error is fatal

This means that this code can not be ran if there are any references to undefined classes in the tree, including classes that are generated by codegen, so, it seems that:

• codegen files should be committed to the repo
• codegen files need to be created before any references to them are added

By comparison, https://github.com/hhvm/user-documentation approach (which has a much less clean implementation than this) is:

• manually written .hhi files are committed to the repo, and do not use hack-specific features
• PHP code is generated as a build step

Split out hackcodegenconfig to an interface and standard implementation