52850e21d8
Previously, such names were visible only on so-called "extended" completion, activated when the hotkey for the basic completion was hit twice. The main reason was that collecting such variants from indexes was a slow process, and we didn't want to harm the responsiveness of completion for basic names. Now it becomes possible thanks to a number of performance optimizations: * Instead of using three separate indexes for classes, functions and variables, we use one -- PyExportedModuleAttributeIndex. By definition, it includes only top-level "importable" names, so we additionally save time by not filtering out irrelevant entries. Also, it doesn't contain private definitions starting with an underscore. It might bother some users, but given that the previous completion was used extremely rarely, and the new one is going to be visible everywhere, it seems that pruning unlikely entries as much as possible is a fare tradeoff. In the future, we might enable them back on the "extended" completion if there is a demand. Also, this index binds its keys to the project (`traceKeyHashToVirtualFileMapping`), further eliminating useless index lookups. * Thanks to the recent fixes in the platform (IJPL-265), it's now possible to simultaneously iterate over all keys in an index and request values for a given key without deadlocks, which is much faster than eagerly fetching all keys first. * While scanning through all matching entries from indexes, we terminate the lookup if the number of items exceeds the size of the lookup list. We can further reduce this number by adjusting the "ide.completion.variant.limit" registry value. * Calculating expensive "canonical" import paths (e.g. "pkg.private.Name" is importable as "pkg.Name") is offloaded to a background thread thanks to the `withExpensiveRenderer` API. We still calculate these paths synchronously, though, for names whose raw qualified names contain components starting with an underscore to decide whether these private names are publicly re-exported and, hence, should be displayed. The rest of the work has been put into reducing the number of entries on the list, e.g. * The prefix under caret is now matched from the beginning of a name, e.g. `Bar<caret>` matches `BarBaz`, but not `FooBar`. * We don't suggest imported names clashing with those already available in scope. * Some kinds of definitions are not suggested in specific contexts, e.g. functions and variables are not suggested inside patterns and type hints. * Nothing is suggested at the top-level of a class body, where dangling reference expressions or calls are not normally expected. Additionally, we don't suggest names from .pyi stubs at the moment, because it pollutes the suggestion list with entries coming from the stubs for third-party packages in Typeshed. We should probably enable them back once we are able to properly disable Typeshed entries for not installed packages. Some legacy forms of completion are left in the extended mode. In particular, qualified names of classes are offered inside string literals only in this mode. Also, module and package names are suggested only in the extended mode, because top-level packages and modules are already suggested for the basic completion by PyModuleNameCompletionContributor. A few tests in PyClassNameCompletionTest were updated or removed entirely because * we no longer suggest private names * we no longer suggest names from private modules not re-exported in a public module * we no longer suggest names clashing with those already available in scope * prefix matching policy was changed to start at the beginning of an identifier The whole feature can be disabled with the option "Suggest importable classes, functions and variables in basic completion" in settings. GitOrigin-RevId: 0787d42ce337b73b01a60f0bb7aa434fee43e659
IntelliJ IDEA Community Edition 
These instructions will help you build IntelliJ IDEA Community Edition from source code, which is the basis for IntelliJ Platform development. The following conventions will be used to refer to directories on your machine:
<USER_HOME>is your home directory.<IDEA_HOME>is the root directory for the IntelliJ source code.
Getting IntelliJ IDEA Community Edition Source Code
IntelliJ IDEA Community Edition source code is available from github.com/JetBrains/intellij-community by either cloning or
downloading a zip file (based on a branch) into <IDEA_HOME>. The default is the master branch.
The master branch contains the source code which will be used to create the next major version of IntelliJ IDEA. The branch names and build numbers for older releases of IntelliJ IDEA can be found on the page of Build Number Ranges.
These Git operations can also be done through the IntelliJ IDEA user interface.
Speed Tip: If the complete repository history isn't needed, then using a shallow clone (git clone --depth 1) will save significant time.
On Windows: Two git options are required to check out sources on Windows. Since it's a common source of Git issues on Windows anyway, those options could be set globally (execute those commands before cloning any of intellij-community/android repositories):
git config --global core.longpaths truegit config --global core.autocrlf input
IntelliJ IDEA Community Edition requires additional Android modules from separate Git repositories. To clone these repositories,
run one of the getPlugins scripts located in the <IDEA_HOME> directory. Use the --shallow argument if the complete repository history isn't needed.
These scripts clone their respective master branches. Make sure you are inside the <IDEA_HOME> directory when running those scripts, so the modules get cloned inside the <IDEA_HOME> directory.
getPlugins.shfor Linux or macOS.getPlugins.batfor Windows.
Note: Always git checkout the intellij-community and android Git repositories to the same branches/tags.
Building IntelliJ Community Edition
Version 2023.2 or newer of IntelliJ IDEA Community Edition or IntelliJ IDEA Ultimate Edition is required to build and develop for the IntelliJ Platform.
Opening the IntelliJ Source Code for Build
Using IntelliJ IDEA File | Open, select the <IDEA_HOME> directory.
- If IntelliJ IDEA displays an error about a missing or out of date required plugin (e.g. Kotlin), enable, upgrade, or install that plugin and restart IntelliJ IDEA.
IntelliJ Build Configuration
- It's recommended to use JetBrains Runtime 17 to compile the project. When you invoke Build Project for the first time, IntelliJ IDEA should suggest downloading it automatically.
- If the Maven plugin is disabled, add the path variable
"MAVEN_REPOSITORY" pointing to
<USER_HOME>/.m2/repositorydirectory. - Make sure you have at least 8GB of RAM on your computer. With the bare minimum of RAM, disable "Compile independent modules in parallel" option in the compiler settings. With notably more memory available, increase "User-local build process heap size" to 3000 - that will greatly reduce compilation time.
Note that it is important to use the variant of JetBrains Runtime without JCEF.
So, if for some reason jbr-17 SDK points to an installation of JetBrains Runtime with JCEF, you need to change it:
ensure that IntelliJ IDEA is running in internal mode (by adding idea.is.internal=true to idea.properties file), navigate to jbr-17
item in Project Structure | SDKs, click on 'Browse' button, choose 'Download...' item and select version 17 and vendor 'JetBrains Runtime'.
Building the IntelliJ Application Source Code
To build IntelliJ IDEA Community Edition from source, choose Build | Build Project from the main menu.
To build installation packages, run the installers.cmd command in <IDEA_HOME> directory. installers.cmd will work on both Windows and Unix systems.
Options to build installers are passed as system properties to installers.cmd command.
You may find the list of available properties in BuildOptions.kt
Examples (./ should be added only for Linux/macOS):
- Build installers only for current operating system:
./installers.cmd -Dintellij.build.target.os=current - Build source code incrementally (do not build what was already built before):
./installers.cmd -Dintellij.build.incremental.compilation=true
installers.cmd is used just to run OpenSourceCommunityInstallersBuildTarget from the command line.
You may call it directly from IDEA, see run configuration Build IDEA Community Installers (current OS) for an example.
Dockerized Build Environment
To build installation packages inside a Docker container with preinstalled dependencies and tools, run the following command in <IDEA_HOME> directory (on Windows, use PowerShell):
docker run --rm -it -v ${PWD}:/community $(docker build -q . --target build_env)
Running IntelliJ IDEA
To run the IntelliJ IDEA built from source, choose Run | Run from the main menu. This will use the preconfigured run configuration "IDEA".
To run tests on the build, apply these setting to the Run | Edit Configurations... | Templates | JUnit configuration tab:
- Working dir:
<IDEA_HOME>/bin - VM options:
-ea
You can find other helpful information at https://www.jetbrains.com/opensource/idea. The "Contribute Code" section of that site describes how you can contribute to IntelliJ IDEA.
Running IntelliJ IDEA on CI/CD environment
To run tests outside of IntelliJ IDEA, run the tests.cmd command in <IDEA_HOME> directory. tests.cmd will work on both Windows and Unix systems.
Options to run tests are passed as system properties to tests.cmd command.
You may find the list of available properties in TestingOptions.kt
Examples (./ should be added only for Linux/macOS):
- Build source code incrementally (do not build what was already built before):
./tests.cmd -Dintellij.build.incremental.compilation=true - Run a specific test:
./tests.cmd -Dintellij.build.test.patterns=com.intellij.util.ArrayUtilTest
tests.cmd is used just to run CommunityRunTestsBuildTarget from the command line.
You may call it directly from IDEA, see run configuration tests in community for an example.