Clarify infer signatures as of now

Author: josevalim

lib/elixir/lib/code.ex

@@ -1578,7 +1578,7 @@ defmodule Code do
   ## Examples
 
       Code.compiler_options(infer_signatures: false)
-      #=> %{infer_signatures: true}
+      #=> %{infer_signatures: [:elixir]}
 
   """
   @spec compiler_options(Enumerable.t({atom, term})) :: %{optional(atom) => term}

lib/elixir/pages/references/gradual-set-theoretic-types.md

@@ -142,7 +142,7 @@ Inferring type signatures comes with a series of trade-offs:
 
   * Cascading errors - when a user accidentally makes type errors or the code has conflicting assumptions, type inference may lead to less clear error messages as the type system tries to reconcile diverging type assumptions across code paths.
 
-On the other hand, type inference offers the benefit of enabling type checking for functions and codebases without requiring the user to add type annotations. To balance these trade-offs, Elixir has a two-steps system, where we first perform inference of functions without type signatures, and then we type check all modules. The inference considers all calls to the same module and any dependency, but assumes calls to modules within the same project to return `dynamic()`, reducing cyclic dependencies and the need for recompilations.
+On the other hand, type inference offers the benefit of enabling type checking for functions and codebases without requiring the user to add type annotations. To balance these trade-offs, Elixir has a two-steps system, where we first perform inference of functions without type signatures, and then we type check all modules. The inference considers all calls within the same module and to Elixir standard library. All other calls are assumed to return `dynamic()`, including calls to modules within the same project as to reduce cyclic dependencies and the need for recompilations. Future Elixir versions will include your project dependencies as part of the inferred modules.
 
 Type inference in Elixir is best-effort: it doesn't guarantee it will find all possible type incompatibilities, only that it may find bugs where all combinations of a type _will_ fail, even in the absence of explicit type annotations. It is meant to be an efficient routine that brings developers some benefits of static typing without requiring any effort from them.