[lolinder]

But what I'm saying is that it does use imports, at least in Rust. I'm assuming that somehow behind the scenes they're concatenating the contents of the imports into the prompt.

I can imagine this is easier in a language like Rust that has a really strict module system, and to be fair the project that I've been using it on is a side project that isn't over 10,000 lines of code yet. If I were up to 30 imports per file I can imagine concatenating would become much less effective.

[adamsmith]

Does it seem to only understand imports of public libraries? If so, it's likely that, rather than understanding the contents of those libraries, it's learning from others' use of those library APIs. If not, it is likely just understanding the words in the API at a shallow depth.

[lolinder]

No, it's imports from other files in my project. It's either using the import or the fact that I have another tab open.

There are definitely times where it produces a close approximation that's obviously just statistical, but there are other times where there's no question that it picked up something from a different source file that couldn't have possibly been in its training set.

I haven't yet decided if it's using imports or opened files in the editor, but it's definitely not just using the single file I have active.

[adamsmith]

It could be doing some "fine tuning" based on the repo. That would be cool! That said, what I meant when referring to 'understanding' the non-local nature of code was in a more principled way.

For example, if an object defined in another file has a function called `rename` that takes zero arguments, when calling it from another file Copilot will likely suggest arguments if there are variables like `old` and `new` near the cursor, even though `rename` actually doesn't take any, just because functions called `rename` typically take arguments. This behavior is in contrast to a tool like an IDE that can trace through the way non-local code references work.