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
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?
|