typeprof 0.10.0 → 0.11.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: 8d68099e4f5d60a45f949d6bfc3a47e8b7d3b7ba66a0794f25f5fe61628de1d1
-  data.tar.gz: 22792d1acb9b16a4150f1afbaf29d59987bf29772908b23075e6668df81a4309
+  metadata.gz: 88521dfb48f311cdb5b651e88afc2627a28040a466a22b50303415531e663cfd
+  data.tar.gz: 4bd17f9d016d6e7a60ed72804eb050a5611af0869275e63d3486700a53befaaf
 SHA512:
-  metadata.gz: 42faa4e3b5c64fd5976e66067bf13339c530785914caad77bc0a405939bc914e9adf78bfbd0aea57a829cb21aed3c6dfc09f8f57def85b09312facd82d33b5a9
-  data.tar.gz: bc6f115fbf1d5292286f04f09d745cfb0c13688a71fdae730d0cfdd903ad8f9f3f9019e532c37b4cf23fe41f39c9a1683f92f28af68716ddf7e625a0efca33f8
+  metadata.gz: f88b069345f02729a09c0516baf4ff31c8aef640adf5a2c53f62f72a9fb8b96b4309993ae79e37ece4ec33972f762005b3898ca7c894cda65c3727513b812b6b
+  data.tar.gz: aa5fec1acd9dd6395d3d16e044f08e7b72fac0f41dc6168683c631fcadca33daf2415b9956ba00cd22c573c6732719fad9eeef3d601a16943d59be6986703c20

data/Gemfile.lock

@@ -1,17 +1,17 @@
 PATH
   remote: .
   specs:
-    typeprof (0.10.0)
-      rbs (>= 0.20.1)
+    typeprof (0.11.0)
+      rbs (>= 1.0.0)
 
 GEM
   remote: https://rubygems.org/
   specs:
     coverage-helpers (1.0.0)
-    docile (1.3.2)
+    docile (1.3.4)
     power_assert (1.2.0)
     rake (13.0.1)
-    rbs (0.20.1)
+    rbs (1.0.0)
     simplecov (0.20.0)
       docile (~> 1.1)
       simplecov-html (~> 0.11)
@@ -36,4 +36,4 @@ DEPENDENCIES
   typeprof!
 
 BUNDLED WITH
-   2.2.1
+   2.2.3

data/doc/demo.md

@@ -39,7 +39,7 @@ class Object
 end
 ```
 
-Yoy can [try this analysis online](https://mame.github.io/typeprof-playground/#rb=def+hello_message%28user%29%0A++%22The+name+is+%22+%2B+user.name%0Aend%0A%0Adef+type_error_demo%28user%29%0A++%22The+age+is+%22+%2B+user.age%0Aend%0A%0Auser+%3D+User.new%28name%3A+%22John%22%2C+age%3A+20%29%0A%0Ahello_message%28user%29%0Atype_error_demo%28user%29&rbs=class+User%0A++attr_reader+name%3A+String%0A++attr_reader+age%3A+Integer%0A%0A++def+initialize%3A+%28name%3A+String%2C+age%3A+Integer%29+-%3E+void%0Aend).
+You can [try this analysis online](https://mame.github.io/typeprof-playground/#rb=def+hello_message%28user%29%0A++%22The+name+is+%22+%2B+user.name%0Aend%0A%0Adef+type_error_demo%28user%29%0A++%22The+age+is+%22+%2B+user.age%0Aend%0A%0Auser+%3D+User.new%28name%3A+%22John%22%2C+age%3A+20%29%0A%0Ahello_message%28user%29%0Atype_error_demo%28user%29&rbs=class+User%0A++attr_reader+name%3A+String%0A++attr_reader+age%3A+Integer%0A%0A++def+initialize%3A+%28name%3A+String%2C+age%3A+Integer%29+-%3E+void%0Aend).
 
 ## A simple demo to generate the signature prototype of "User" class
 

data/doc/todo.md

@@ -0,0 +1,133 @@
+# TypeProf milestones and TODOs
+
+## Big milestones
+
+### Rails support
+
+There are many known issues for the analysis of typical Ruby programs including Rails apps.
+
+* The main difficulty is that they use many language extensions like `ActiveSupport`.
+  Some features (for example, `blank?` and `Time.now + 1.day`) are trivial to support,
+  but others (for example, `ActiveSupport::Concern` and Zeitwerk) will require special support.
+* The other difficulty is that they heavily use meta-programming features like `ActiveRecord`.
+  It dynamically defines some methods based on external data (such as DB schema) from the code.
+
+Currently, projects called [`gem_rbs`](https://github.com/ruby/gem_rbs) and [`rbs_rails`](https://github.com/pocke/rbs_rails) are in progress.
+The former provides several RBS files for some major gems including Rails.
+The latter is a tool to generate RBS prototype of a target Rails application by introspection (executing it and monitoring DB schema, etc).
+TypeProf can use their results to improve analysis precision and performance.
+
+What we need to do:
+
+* Experimentally apply TypeProf to some Rails programs and identify problems
+* Make TypeProf able to work together with `rbs_rails` for supporting trivial core extensions and `ActiveRecord`.
+* Implement special support for some fundamental language extensions of Rails like `ActiveSupport::Concern`.
+  (It would be best if TypeProf has a plugin system and if we can factor out the special support as a plugin for Rails.)
+
+### Error detection and diagnosis feature
+
+At present, TypeProf focuses on generation of RBS prototype from no-type-annotated Ruby code.
+However, it is possible for TypeProf to report possible errors found during the analysis.
+In fact, an option `-v` experimentally shows possible errors found.
+There are some reasons why it is disabled by default:
+
+* (1) There are too many false positives.
+* (2) Some kind of error reporting is not implemented yet.
+* (3) Some reported errors are difficult for a user to understand.
+
+For (1), we will research how we can avoid false positives to support typical Ruby coding patterns as much as possible.
+The primary way is to improve the analysis precision, e.g., enhancing flow-sensitive analysis.
+If the S/N ratio of an error type is too low, we need to consider to suppress the kind of reports.
+Also, we may try allowing users to guide TypeProf to analyze their program well.
+(The simplest way is to write inline type casts in the code, but we need to find more Ruby/RBS way.)
+We may also explore a "TypeProf-friendly coding style" which TypeProf can analyze well.
+(In principle, the plainer code is, the better TypeProf can analyze.)
+
+For (2), currently, TypeProf checks the argument types of a call to a method whose type signature is declared in RBS.
+However, it does not check the return type yet. Redefinition of constants should be warned too.
+We will survey what errors and warnings TypeProf can print, and evaluate the S/N ratio of each report.
+
+For (3), since TypeProf uses whole program analysis, an error may be reported at a very different place from its root bug.
+Thus, if TypeProf shows a possible type error, a diagnosis feature is needed to answer why TypeProf thinks that the error may occur.
+TypeProf has already implemented a very primitive diagnosis feature, `Kernel#p`, to check what type an expression has.
+Another idea is to create a pseudo backtrace why TypeProf thought the possible type error may occur.
+We should consider this feature with LSP support.
+
+### Performance improvement
+
+Currently, TypeProf is painfully slow. Even if a target application is small.
+
+The main reason is that TypeProf analyzes not only the application code but also library code:
+if an application requires `"foo"`, TypeProf actually loads `foo.rb` even from a gem,
+and furthermore, if `foo.rb` requires `"bar"`, it loads `bar.rb` recursively.
+
+RBS will help to stop this cascade;
+when an application requires `"foo"`, TypeProf loads `sig/foo.rbs` instead of `foo.rb` if the `foo` gem contains both.
+Such a RBS file is optional for TypeProf but required for Steep.
+So, we think many gems will eventually equip their RBS declarations.
+
+That being said, we should continue to improve the analysis performance of TypeProf. We have some ideas.
+
+* Unfortunately, TypeProf often analyzes one method more than once when it accepts multiple types.
+  As TypeProf squashes the argument types to a union, this duplicated analysis is not necessarily needed.
+  But when TypeProf first analyzes a method, it is difficult to determine if the method will accept another type in further analysis.
+  So, we need good heuristics to guess whether a method accepts multiple types or not, and if so, delay its analysis.
+* Currently, TypeProf executes the bytecode instructions step by step.
+  This requires creating an environment object after each instruction, which is very heavy.
+  Many environment creations can be omitted by executing each basic block instead of each instruction.
+  (Basic block execution will also make flow-sensitive analysis easier.)
+* The slowest calculation in TypeProf is to create an instance of a Type class.
+  The creation uses memoization; TypeProf keeps all Type instances created so far, and reuses them if already exist.
+  However, it is very heavy to check if an instance already exists or not.
+  (Currently, it is very simply implemented by a big Hash table.)
+  We've already improved the memoization routine several times but looks like it is still the No.1 bottleneck.
+  We need to investigate and try improving more.
+* TypeProf heavily uses Hash objects (including above) mainly to represent a set.
+  A union of sets is done by `Hash#merge`, which takes O(n).
+  A more lightweight data structure may make TypeProf faster.
+  (But clever structure often has a big constant term, so we need to evaluate the performance carefully.)
+* Reusing an old analysis and incrementally updating it will bring a super big improvement.
+  This would be especially helpful for LSP support, so we need to tackle it after the analysis approach is mature.
+
+### Language Server Protocol (LSP) support
+
+In the future, we want TypeProf to serve as a language server to show the result in IDE in real-time.
+However, the current analysis approach is too slow for IDE. So we need to improve the performance first.
+
+Even if TypeProf becomes fast enough, its approach has a fundamental problem.
+Since TypeProf uses whole program analysis, one edit may cause a cascade of propagation:
+if a user write `foo(42)`, an Integer is propagated to a method `foo`,
+and if `foo` passes its argument to a method `bar`, it is propagated to `bar`, ...
+So, a breakthrough for LSP may be still needed, e.g, limiting the propagation range in real-time analysis,
+assuming that a type interface of module boundary is fixed, etc.
+
+## Relatively smaller TODOs
+
+* Support more RBS features
+  * TypeProf does not deal with some RBS types well yet.
+    * For example, the `instance` type is handled as `untyped.
+    * The `self` type is handled well only when it is used as a return type.
+    * Using a value of the `void` type should be warned appropriately.
+  * RBS's `interface` is supported just like a module (i.e., `include _Foo` is explicitly required in RBS),
+    but it should be checked structually (i.e., it should be determined as a method set.)
+  * The variance of type parameters is currently ignored.
+
+* Support more Ruby features
+  * Some meta-programming features like `Class.new`, `Object#method`, etc.
+    * It is possible to support `Class.new` by per-allocation-site approach:
+      e.g., In TypeProf, `A = Class.new; B = Class.new` will create two classes, but `2.times { Class.new }` will create one class.
+  * The analysis precision can be improved more for some Ruby features like pattern matching, keyword arguments, etc.
+    * For example, `foo(*args, k:1)` is currently compiled as if it is `foo(*(args + [{ :k => 1 }]))` into Ruby bytecode.
+      This mixes the keyword arguments to a rest array, and makes it difficult for TypeProf to track the keyword arguments.
+  * Support Enumerator as an Array-type container.
+  * Support `Module#protect` (but RBS does not yet).
+  * More heuristics may help such as `==` returns a bool regardless to its receiver and argument types.
+
+* Make TypeProf more useful as a tool
+  * Currently, TypeProf provides only the analysis engine and a minimal set of features.
+  * The analysis result would be useful not only to generate RBS prototype
+    but also identifying the source location of a method definition, listing callsites of a method,
+    searching a method call by its argument types, etc.
+  * Sometimes, TypeProf prints very big union type, such as `Integer | Float | Complex | Rational | ...`.
+    Worse, the same big type is printed multiple times.
+    It may be useful to factor out such a long type by using type alias, for example.

data/lib/typeprof/cli.rb

@@ -20,6 +20,7 @@ module TypeProf
       options = {}
       dir_filter = nil
       gem_rbs_features = []
+      gem_repo_dirs = []
       show_version = false
       max_sec = max_iter = nil
 
@@ -31,6 +32,7 @@ module TypeProf
       opt.on("--version", "Display typeprof version") { show_version = true }
       opt.on("-I DIR", "Add DIR to the load/require path") {|v| $LOAD_PATH << v }
       opt.on("-r FEATURE", "Require RBS of the FEATURE gem") {|v| gem_rbs_features << v }
+      opt.on("--repo DIR", "Add DIR to the RBS repository") {|v| gem_repo_dirs << v }
 
       opt.separator ""
       opt.separator "Analysis output options:"
@@ -87,6 +89,7 @@ module TypeProf
         rbs_files: rbs_files,
         output: output,
         gem_rbs_features: gem_rbs_features,
+        gem_repo_dirs: gem_repo_dirs,
         verbose: verbose,
         dir_filter: dir_filter,
         max_sec: max_sec,

data/lib/typeprof/config.rb

@@ -6,6 +6,7 @@ module TypeProf
     :rbs_files,
     :output,
     :gem_rbs_features,
+    :gem_repo_dirs,
     :verbose,
     :dir_filter,
     :max_iter,
@@ -25,6 +26,7 @@ module TypeProf
     def initialize(**opt)
       opt[:output] ||= $stdout
       opt[:gem_rbs_features] ||= []
+      opt[:gem_repo_dirs] ||= []
       opt[:dir_filter] ||= DEFAULT_DIR_FILTER
       opt[:verbose] ||= 0
       opt[:options] ||= {}

data/lib/typeprof/import.rb

@@ -3,6 +3,10 @@ require "rbs"
 module TypeProf
   class RBSReader
     def initialize
+      @repo = RBS::Repository.new
+      Config.gem_repo_dirs.each do |dir|
+        @repo.add(Pathname(dir))
+      end
       @env, @builtin_env_json = RBSReader.get_builtin_env
     end
 
@@ -11,7 +15,7 @@ module TypeProf
       unless @builtin_env
         @builtin_env = RBS::Environment.new
 
-        loader = RBS::EnvironmentLoader.new
+        loader = RBS::EnvironmentLoader.new(repository: @repo)
         new_decls = loader.load(env: @builtin_env).map {|decl,| decl }
         @builtin_env_json = load_rbs(@builtin_env, new_decls)
       end
@@ -24,7 +28,7 @@ module TypeProf
     end
 
     def load_library(lib)
-      loader = RBS::EnvironmentLoader.new(core_root: nil)
+      loader = RBS::EnvironmentLoader.new(core_root: nil, repository: @repo)
       loader.add(library: lib)
 
       case lib
@@ -38,7 +42,7 @@ module TypeProf
     end
 
     def load_path(path)
-      loader = RBS::EnvironmentLoader.new(core_root: nil)
+      loader = RBS::EnvironmentLoader.new(core_root: nil, repository: @repo)
       loader.add(path: path)
       new_decls = loader.load(env: @env).map {|decl,| decl }
       RBSReader.load_rbs(@env, new_decls)

data/lib/typeprof/version.rb

@@ -1,3 +1,3 @@
 module TypeProf
-  VERSION = "0.10.0"
+  VERSION = "0.11.0"
 end

data/typeprof.gemspec

@@ -30,5 +30,5 @@ Gem::Specification.new do |spec|
   spec.executables   = spec.files.grep(%r{^exe/}) { |f| File.basename(f) }
   spec.require_paths = ["lib"]
 
-  spec.add_runtime_dependency "rbs", ">= 0.20.1"
+  spec.add_runtime_dependency "rbs", ">= 1.0.0"
 end

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: typeprof
 version: !ruby/object:Gem::Version
-  version: 0.10.0
+  version: 0.11.0
 platform: ruby
 authors:
 - Yusuke Endoh
 autorequire: 
 bindir: exe
 cert_chain: []
-date: 2020-12-18 00:00:00.000000000 Z
+date: 2020-12-24 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: rbs
@@ -16,14 +16,14 @@ dependencies:
     requirements:
     - - ">="
       - !ruby/object:Gem::Version
-        version: 0.20.1
+        version: 1.0.0
   type: :runtime
   prerelease: false
   version_requirements: !ruby/object:Gem::Requirement
     requirements:
     - - ">="
       - !ruby/object:Gem::Version
-        version: 0.20.1
+        version: 1.0.0
 description: |
   TypeProf performs a type analysis of non-annotated Ruby code.
 
@@ -48,6 +48,7 @@ files:
 - doc/doc.ja.md
 - doc/doc.md
 - doc/ppl2019.pdf
+- doc/todo.md
 - exe/typeprof
 - lib/typeprof.rb
 - lib/typeprof/analyzer.rb
@@ -402,7 +403,7 @@ required_rubygems_version: !ruby/object:Gem::Requirement
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
-rubygems_version: 3.1.4
+rubygems_version: 3.2.3
 signing_key: 
 specification_version: 4
 summary: TypeProf is a type analysis tool for Ruby code based on abstract interpretation