You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

43 lines
2.9 KiB
Plaintext

AHACAT - Advanced High-Accuracy Code Analysis Toolkit
parsing
scope tracking - tie particular variables to particular identifiable scopess
reassignment tracking - indicate which 'generation' of a variable a particular reference belongs to
in cases where the generation is ambiguous because it eg. depends on the call time (which should probably be a warning!), indicate this as well by specifying the 'generation coverage', ie. the possible generations that it *could* be referring to
deterministic function identifiers, by hashing the function's contents?
recursive hashing of functions, like Nix does?
trait generation based on property assignment codepaths
track property conflicts for objects that have multiple values for the same property
make explicit property checks exclude an object from trait validation? or is this inherently allowed in the required trait signature caused by the property check?
(consider branching, both for trait definitions and usage!)
special cases with scoping/references:
* direct vs indirect eval
* in non-strict mode, eval modifies the scope it's called in
* in non-strict mode, `arguments` is tied to the assigned parameter names in the function definition; changing one changes the other
* composite types (made up of traits)
* traits (made up of sets of properties)
* properties (name + type)
* types (primitive types, composite types, or function types)
* function types (each function is its own type - how to deal with different call signatures?)
how to deal with deduplication of type-identical traits/interfaces that are defined in different places?
how to do this in the context of recursion?
how to approach this in the context of cyclic references between the to-be-deduplicated types?
mark a function as exported when:
* it is made available in the global scope
* it is exported through a module system (`module.exports`, `export`, ...)
* it is exposed as a function object directly from the module, eg.:
* as a return value from another exported function
* as a method of an object that is returned from some other (directly or indirectly) exported function
* accessible, directly or indirectly, through an argument to a callback that is provided externally from the module (eg. hooks)
an exported function can, for example, never be eliminated as 'dead code', unless *all* of the possible call sites (ie. every place where it is directly or indirectly made accessible through an 'import' of some sort) have been analyzed, and determined not to use it
* Dead code detection; distinction between 'in isolation' and 'in context' because the former is useful for error detection whereas both are useful for eg. bundle optimization
* Detect dead code in isolation; functions (and objects of functions?) that are neither exported, nor accessed indirectly through anything that *is* exported, nor called upon module load
* Detect dead code in context; functions that are exported but never called. Possibly other non-accessed data as well?