REPLCompletions: replace get_type by the proper inference

[aviatesk]

This PR generalizes the idea from #49199 and uses inference to analyze
the types of REPL expression. This approach offers several advantages
over the current get_[value|type]-based implementation:

• The need for various special cases is eliminated, as lowering normalizes
  expressions, and inference handles all language features.
• Constant propagation allows us to obtain accurate completions for complex
  expressions safely (see Use const propagating inference in REPL tab completions #36437).

Analysis on arbitrary REPL expressions can be done by the following steps:

• Lower a given expression
• Form a top-level MethodInstance from the lowered expression
• Run inference on the top-level MethodInstance

This PR implements REPLInterpreter, a custom AbstractInterpreter that:

• aggressively resolves global bindings to enable reasonable completions
  for lines like Mod.a.| (where | is the cursor position)
• aggressively concrete-evaluates :inconsistent calls to provide
  reasonable completions for cases like Ref(Some(42))[].|
• does not optimize the inferred code, as REPLInterpreter is only used
  to obtain the type or constant information of given expressions

Aggressive binding resolution presents challenges for REPLInterpreter's
cache validation (since #40399 hasn't been resolved yet). To avoid cache
validation issue, REPLInterpreter only allows aggressive binding
resolution for top-level frame representing REPL input code
(repl_frame) and for child getproperty frames that are
constant propagated from the repl_frame. This works, since
1.) these frames are never cached, and
2.) their results are only observed by the non-cached repl_frame

REPLInterpreter also aggressively concrete-evaluates :inconsistent
calls within repl_frame, allowing it to get get accurate type
information about complex expressions that otherwise can not be constant
folded, in a safe way, i.e. it still doesn't evaluate effectful
expressions like pop!(xs). Similarly to the aggressive binding
resolution, this aggressive concrete evaluation doesn't present any cache
validation issues because it is limited to repl_frame that is never cached.

Also note that the code cache for REPLInterpreter is separated from the
native code cache, ensuring that code caches produced by REPLInterpreter,
where bindings are aggressively resolved and the code is not really
optimized, do not affect the native code execution. A hack has
also been added to avoid serializing CodeInstancess produced by
REPLInterpreter during precompilation to workaround #48453.

closes #36437
replaces #49199

[aviatesk]

@nanosoldier runbenchmarks(!"scalar", vs=":master")

[oscardssmith]

Can you make it so this is able to concrete eval through non-consistent code?

[aviatesk]

It might be reasonable to enable concrete eval for inconsistent calls limitedly, but we first need to finish #47154 in order to constant fold arrays.

[staticfloat]

as a fun little bonus, this approach is actually more correct when analyzing the degenerate case:

struct UnstableFoo
end
function Base.propertynames(::UnstableFoo)
    if rand() > 0.5
        return (:a, :b)
    else
        return (:a, :b, :c)
    end
end

struct Wrap
    a
end

julia> Wrap(UnstableFoo()).a.
a  b  c
julia> Wrap(UnstableFoo()).a.
a  b

[staticfloat]

Hmmm, playing around with this a bit, I did notice that unusual symbol names (such as those that might require use of var"" to access them) can confuse the tab autocompletion, since the var"" syntax looks like a string, and so it starts to auto-suggest filenames, rather than symbol names:

julia> struct WeirdNames
       end
       Base.propertynames(::WeirdNames) = (Symbol("oh no!"), Symbol("oh yes!"))

julia> WeirdNames().var"oh 
.buildkite-external-version  .clang-format                .clangd                      .codecov.yml                 .devcontainer/               .git-blame-ignore-revs
.git/                        .gitattributes               .github/                     .gitignore                   .mailmap                     CITATION.bib
CITATION.cff                 CONTRIBUTING.md              HISTORY.md                   LICENSE.md                   Make.inc                     Makefile
NEWS.md                      README.md                    THIRDPARTY.md                VERSION                      base/                        cli/
contrib/                     deps/                        doc/                         etc/                         julia                        julia.spdx.json
pkgimage.mk                  src/                         stdlib/                      sysimage.mk                  test/                        usr-staging/
usr/

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

[aviatesk]

I did notice that unusual symbol names (such as those that might require use of var"" to access them) can confuse the tab autocompletion, since the var"" syntax looks like a string, and so it starts to auto-suggest filenames, rather than symbol names:

Yes, you're right. This specific issue isn't related to this PR since it comes from our handling of REPL input code, which occurs before the type analysis step. We should definitely improve it, likely in a separate PR.

[aviatesk]

Can you make it so this is able to concrete eval through non-consistent code?

Implemented. Now we can get completions for cases like Ref(Some(42))[].|. Combined with #47154, we will be able to get completions for cases like Any[Some(42)].| also.

[aviatesk]

@nanosoldier runbenchmarks("linalg" || "inference" || "sparse", vs=":master")

[nanosoldier]

Your benchmark job has completed - possible performance regressions were detected. A full report can be found here.

[StefanKarpinski]

What a cool and practical use of our effect analysis!