| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |\
| |
| | |
SI-7995 completion imported vars and vals
|
| | |
| |
| |
| |
| |
| | |
Imported member vals and vars were always marked inaccessible, even
if referencing them at the location of the completion is valid in code.
The accessible flag is now set accordingly to the accessibility of the getter.
|
| |\ \
| |/
|/| |
make askLoadedType unload arguments out of the PC by default,
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The rationale for not keeping units loaded by default is that the more
units are loaded, the slower is background compilation. For instance, in
the Scala IDE for Eclipse (which uses the presentation compiler),
typechecking occurs every time the reconciler kicks-in (~500millis after
you stop typing), hence it is important that units are not kept loaded
unless strictly necessary (for some extra information about this, see
https://www.assembla.com/spaces/scala-ide/tickets/1001388)
While I agree that using a boolean argument (`keepLoaded`) for deciding
if a unit should be loaded isn't a great design, other methods in
`CompilerControl` also have a keepLoaded parameter, so at least we have
some consistency. For the future, I'm thinking we should be able to
remove the `keepLoaded` flag altogether, and change the implementation
of `askLoadedType` to preserve the same units loaded in the presentation
compiler before and after its execution. Basically, if you want a unit
to be kept loaded, you should call `askReload` first, and then
`askLoadedType`. However, to reduce impact, I think the changes carried
by this commit will help us estimate if the solution I just outlined is
viable (because `askLoadeType` won't be keeping units loaded by default,
which wasn't the case with the former implementation).
(While the patch was mostly contributed by @huitseeker, @dotta has edited the
commit message to preserve the comments in the PR
https://github.com/scala/scala/pull/3209)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Otherwise we can think that `+` in `1 + BigInt(2)` refers
to a method in `Int`.
In general, this protects the IDE from observing results from
"exploratory" typing which is discarded as the compiler backtracks
to another possibility.
This protection subsumes the condition that checked for overloaded
types: presentation/t7458 now passes without this.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We shouldn't observe tree types under silent mode.
The enclosed test is a standalone version of `1 + BigInt(2)`,
a standard example of exploratory typing in Scala. Once we determine
that none of the `+` methods in `Int` accepts (possibly implicitly
coerced `BigInt`), we have to backtrack and look for a view from
`Int => { +(_: BigInt): ? }`.
The next commit will correct the problem.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
targeted type-checked
When asking for targeted typecheck, the located tree may have overloaded types
is the source isn't yet fully typechecked (e.g., a select tree for an
overloaded method). This is problematic as it can lead to unknown 'hovers',
broken hyperlinking that suddenly starts working, unresolved ScalaDoc comments,
and similar, in the Scala IDE.
With this commit we are hardening the contract of `askTypeAt` to return the
same type whether the file was fully type-checked or targeted type-checked.
This is done by preventing the typechecker to stop too early if the `located`
tree has an overloaded type. Furthermore, I'm assuming that if `located.tpe`
is of type `OverloadedType`, by letting the compiler carry-on the typechecking,
the `located.tpe` will eventually be resolved to a non-overloaded type. Said
otherwise, I expect the targeted typechecking will always terminate (if my
reasoning isn't sound, please say so).
The test provided with this commit demonstrates the new behavior (the position
used to execute the test is resolved to the `foo` method's call). In fact,
before this commit, executing the test returned the following:
(x: Int, y: String)Unit <and> (x: String)Unit <and> (x: Int)Unit
Showing that the tree's type is an overloaded type. The ambiguity is fixed by
this commit, and in fact the test's output is now:
(x: Int)Unit
|
| |\
| |
| | |
Backport of
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
Updates localeContext() to return the best context possible when there are none directly
associated with the given position. It happens when an expression cannot be
successfully typed, as no precise ContextTree covers the expression location, or if the
position is not inside any expression.
Adds corresponding tests
(cherry picked from commit 3028327e2a2b553b12ee45519413515c8aa0865f)
|
| | |
| |
| |
| | |
(cherry picked from commit 3d55fe723f1af91f4d2db421f0e0965c583346dc)
|
| | |
| |
| |
| |
| |
| | |
Adds a new marker /*_*/ to trigger scope completion test.
Original type completion test oracles update for the tweaked output
(cherry picked from commit 9c7c66ff7907e3ab814f0f4375eeaf6cdd230d5e)
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The tree created during expansion of default arguments contained trees with the
wrong type of positions. Let's discuss this with an example. Below is the tree
generated for the `foo` method in the test class included in this commit.
Before this commit:
```
[54:94]def foo(): [58]Unit = <70:90>{
[70:79]<artifact> val qual$1: [70]Bar = [70:79][70:79][70:79]new [74:77]Bar();
[80]<artifact> val x$1: [80]Int = [80]qual$1.bar$default$1;
<70:90><70:83>qual$1.bar([80]x$1)
}
```
Now:
```
[54:99]def foo(): [58]Unit = <70:95>{
<70:84><artifact> val qual$1: [70]Bar = [70:84][70:84][70:84]new [74:77]Bar();
[85]<artifact> val x$1: [85]Int = [85]qual$1.bar$default$1;
<70:95>[84:88]qual$1.bar([85]x$1)
}
```
Here are the list of changes:
* The synthetic `qual$1` has a transparent position, instead of a range position.
* The new Select tree (i.e., `qual$1.bar`) should always have a range position,
because `selected` (i.e., the called method) is always visible in the source
(in fact, this is the whole point of the fix, we need a range position or
hyperlinking request from the Scala IDE won't work).
* The Block that contains the expanded default arguments is forced to have a
transparent position, as it never exist in the original source.
The tricky part of the fix is the position assigned to the new Select tree,
which needs to respect the range position's invariants. In the specific case,
we ought to make sure that range positions don't overlap. Therefore, the position
assigned to the new Select tree is computed by intersecting the original Select
position (i.e., `baseFun`'s position) and the original qualifier's position
(i.e., `qual`'s position).
If you take a closer look at the range positions assigned in the tree after this
commit, you'll notice that the range position of the `qual$1`'s rhs (i.e.,
[70:84]), and `qual$1.bar` (i.e., [84:88]) might seem to overlap, because the
former ends where the latter begins. However, this not the case because of the
range position's invariant 2, which states:
> Invariant 2: in a range position, start <= point < end
Hence, the above two positions aren't overlapping as far as the compiler is
concerned.
One additional aspect (that may look like a detail) is that we make sure to
never generate a position such that its start is after its end. This is why we
take the position with the smallest end point.
Furthermore, calling `withStart` would turn any position in a range position,
which isn't desiderable in general (and, even worse, this can lead to
generation of invalid positions - bad offsets - if the computation is performed
on offset positions). Hence, the position's computation is only performed when
both `baseFun` and `qual` positions are range positions. Indeed, I expect this to
be always the case if the compiler is started with -Yrangepos.
(cherry picked from commit 3009a525b58a4c7865ff524899b85518884ee5f7)
|
| |
|
|
|
|
|
|
|
|
|
|
| |
`List(1, 2, 3).map(f).<ctrl-space>` now works; before
the tree had the type `(bf: CanBuildFrom[...]):...` and
did not contribute completions from the result type.
This commit checks if the tree has an implicit method
type, and typechecks it as a qualifier. That is enough
to get to `adaptToImplicitMethod` in the type checker,
infer the implicit arguments, and compute the final result
type accordingly.
|
| |
|
|
|
|
|
|
| |
Francois is investigating the root cause as part of his
work on stabilizing Scaladoc preview in the IDE.
The test seems to only fail on the windows nightly build.
I suspect this is due to a slower or loaded machine.
|
| |
|
|
|
|
|
| |
Don't focus positions assigned to the TypeTree of a parent of a Template
when the parent exists in the source. A focused position (instance
of `OffsetPosition`) makes it invisible to the presentation compiler
when it looks for the innermost enclosing tree of a given position
(breaking hyperlinking, for example).
|
| |
|
|
|
|
| |
for given fragments. Don't type-check when forcing doc comments, but rather
do it directly. Test the new functionality as well as better tests for
the old one.
|
| |\
| |
| | |
SI-7134: don't require doc.Settings in base api of scaladoc.
|
| | | |
|
| |/ |
|
| |\
| |
| | |
SI-7026 Asking for a parse tree will now never result in a typed tree
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit fixes ticket SI-7026. This makes it safe to use
parseTree outside of the presentation compiler thread.
Solved it with an implementation that just parses the source every
time without trying to memorize anything. Added tests that checks
that
1. You get a new parse tree every time you ask for one.
2. You always get a parse tree, never a typed tree.
3. A parse tree should never contain any symbols or types [1].
4. If you ask for a parse tree and then ask for a typed tree it
shouldn't change the parse tree you originally asked for, i.e.
property 3 still holds.
Additionally the parser is now only interruptible when running
on the presentation compiler thread.
[1] There is an exception to this though. Some of the nodes that
the compiler generates will actually contain symbols. I've
chosen to just ignore these special cases for now.
|
| |/
|
|
| |
Refactor scaladoc base functionality to allow it to be mixed in with Global in the IDE.
|
| | |
|
| |
|
|
|
|
|
| |
shutdown.
When the compiler is asked to shutdown, it may still have items on the working queue, and more can be added by clients in other thread that don't *know* the compiler is down yet. These requests were never serviced, leading to deadlocks or timeouts.
review by @odersky, @hubertp
|
| |
|
|
|
| |
Fix #6312.
review by @odersky,@lrytz.
|
| |
|
|
| |
Removes the two global hash maps in Namers, and the one in NamesDefaults. Also fixes SI-5975.
|
| |
|
|
|
|
|
|
|
|
| |
* Removed unneeded .flags.
* Renamed a few methods in `InteractiveTest`.
* Force the presentation compiler to shut down after each test.
* -sourcepath in the .flags file is now relative to the test's base directory.
* Use `InteractiveReporter` in Presentation Compiler tests.
By using the `InteractiveReporter`, compilation errors are collected in the
compilation unit. This was necessary for testing SI-5975.
|
| | |
|
| |
|
|
|
|
| |
* Move method into TraversableOnce from Iterator and Traversable to make the build pass.
* Udpate IDE tests with new collection methods.
* Rewire default toXYZ methods to use convertTo.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before 2.10 we had a notion of ClassManifest that could be used to retain
erasures of abstract types (type parameters, abstract type members) for
being used at runtime.
With the advent of ClassManifest (and its subtype Manifest)
it became possible to write:
def mkGenericArray[T: Manifest] = Array[T]()
When compiling array instantiation, scalac would use a ClassManifest
implicit parameter from scope (in this case, provided by a context bound)
to remember Ts that have been passed to invoke mkGenericArray and
use that information to instantiate arrays at runtime (via Java reflection).
When redesigning manifests into what is now known as type tags, we decided
to explore a notion of ArrayTags that would stand for abstract and pure array
creators. Sure, ClassManifests were perfectly fine for this job, but they did
too much - technically speaking, one doesn't necessarily need a java.lang.Class
to create an array. Depending on a platform, e.g. within JavaScript runtime,
one would want to use a different mechanism.
As tempting as this idea was, it has also proven to be problematic.
First, it created an extra abstraction inside the compiler. Along with class tags
and type tags, we had a third flavor of tags - array tags. This has threaded the
additional complexity though implicits and typers.
Second, consequently, when redesigning tags multiple times over the course of
Scala 2.10.0 development, we had to carry this extra abstraction with us, which
exacerbated the overall feeling towards array tags.
Finally, array tags didn't fit into the naming scheme we had for tags.
Both class tags and type tags sound logical, because, they are descriptors for
the things they are supposed to tag, according to their names.
However array tags are the odd ones, because they don't actually tag any arrays.
As funny as it might sound, the naming problem was the last straw
that made us do away with the array tags. Hence this commit.
|
| | |
|
| | |
|
| |
|
|
|
| |
Wasn't me this time (I don't think!) Mr. Robot can't get
here too soon for me.
|
| | |
|
| |
|
|
|
|
| |
conjunction with implicit arguments).
Removed even more code in the presentation compiler testing infrastructure. One less level of indirection,
and a top-level object gone!
|
| |
|
|
| |
Oh boy, a checkfile! This is the best christmas ever!
|
| | |
|
| |
|
|
| |
Removed some unneeded indirection in the testing framework.
|
| |\ \ |
|
| | |/
|/| |
|
| |/
|
|
|
|
| |
This test ensures hyperlinking works inside and around pattern matching. The new virtual pattern matcher
synthesizes trees that are not properly nested, and whose positions make it impossible to retrieve the correct
tree/symbol for a given position. Therefore, the current test is using the old pattern matcher. However,
once the virtual pattern matcher is fixed, remove the corresponding line from patmat.flags to re-enable virtpatmat.
|
| |
|
|
|
| |
* all usages of ClassManifest and Manifest are replaced with tags
* all manifest tests are replaced with tag tests
|
| |
|
|
|
|
|
| |
some tests (unreachability, exhaustivity, @switch annotation checking) are still run under -Xoldpatmat,
but that will change before we go into RC mode (then the test/ partest of this commit will be reverted)
removed irrelevant dependency on patmat
|
| |
|
|
|
|
|
|
|
|
| |
I turn them over to the responsible parties. Iulian knows about
the deadlock test; for philipp I presume,
07:10:29 [partest] concurrent-future.scala:97: error: not found: type FutureTimeoutException
07:10:29 [partest] throw new FutureTimeoutException(null)
07:10:29 [partest] ^
07:10:29 [partest] one error found
|
| |
|
|
| |
make it much more resilient against spikes. Also removed usedmem file dumps.
|
| | |
|
| |
|
|
|
| |
Yet more funnelling of immutable creation-time known information
into the identities of symbols and types.
|
| |
|
|
| |
shutdown test more resilient on slow machines.
|
| |
|
|
|
|
|
| |
During shutdown, other threads can still post work items on the work queue. They will never be serviced,
leading to clients waiting forever.
The fix is to replace the implementation of the queue with a 'always fail' implementation during shutdown.
Review by @odersky.
|
| |
|
|
| |
Functions of functions use parens for grouping.
|
