Skip to content

Don't force NamedType denotations in containsRefinedThis #1026

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 12 commits into from

Conversation

odersky
Copy link
Contributor

@odersky odersky commented Jan 14, 2016

containsRefinedThis inspects symbols and infos of named types in order
to avoid needless traversals. As i974 shows, this can lead to infinite
recursions. The fix is not to force a NamedType denotation, assume the
worst and traverse the prefix if a NamedType is not yet populated
with a denotation.

Fixes #974 and makes MutableSortedSetFactory in stdlib compile.

Review by @smarter

@odersky
Copy link
Contributor Author

odersky commented Jan 14, 2016

/rebuild

@odersky
Copy link
Contributor Author

odersky commented Jan 14, 2016

It was a GC overhead limit exceeded again. Is there a way to increase the heap or alternatively reduce the level of parallelism?

@odersky
Copy link
Contributor Author

odersky commented Jan 14, 2016

Out of heap space this time. We need to change the build script to take more heap. Can someone do this please?

@smarter
Copy link
Member

smarter commented Jan 14, 2016

I think this PR only addresses the symptoms and not the root of the problem, which is that we do not check for cycles in the prefixes of TypeRefs which are RefinementTypes. For example, the following causes an infinite loop instead of printing illegal cyclic reference: upper bound Bar[T]#Elem of type T refers back to the type itself:

trait Foo[T <: Bar[T]#Elem]
trait Bar[T] {
  type Elem = T
}

@odersky
Copy link
Contributor Author

odersky commented Jan 14, 2016

The two problems are unrelated. #974 caused the StackOverflow before the
cycle check was even run.
@smarter, can you make this new failing test into a separate issue?

On Thu, Jan 14, 2016 at 5:05 PM, Guillaume Martres <[email protected]

wrote:

I think this PR only addresses the symptoms and not the root of the
problem, which is that we do not check for cycles in the prefixes of
TypeRefs which are RefinementTypes. For example, the following causes an
infinite loop instead of printing illegal cyclic reference: upper bound
Bar[T]#Elem of type T refers back to the type itself:

trait Foo[T <: Bar[T]#Elem]trait Bar[T] {
type Elem = T
}


Reply to this email directly or view it on GitHub
#1026 (comment).

Martin Odersky
EPFL

@smarter
Copy link
Member

smarter commented Jan 14, 2016

Are you sure? If I apply the following on top of master: https://github.com/dotty-staging/dotty/commits/try/refinement-cycles then tests/pos/i974.scala succeeds as well as my example above (however, other tests like ./tests/pos/tcpoly_ticket2096.scala now fail)

@odersky
Copy link
Contributor Author

odersky commented Jan 14, 2016

@smarter Maybe you are right. I fixed checkNonCyclic and your example compiles OK (i.e. with errors) now.

@odersky
Copy link
Contributor Author

odersky commented Jan 14, 2016

The heap problem has gone away. We are back to the previous

pos/printing: compilation failed

without any further diagnostic. It's super urgent that we fix this, no progress is possible without it.

@smarter
Copy link
Member

smarter commented Jan 14, 2016

/rebuild

@smarter
Copy link
Member

smarter commented Jan 14, 2016

@odersky : Maybe try rebasing on master where the partest jenkins job does not use bootstrapped dotty anymore.

@DarkDimius
Copy link
Contributor

Ok. I was able to get to the archives of workspace.
But the log does no say much. eg, for
https://scala-ci.typesafe.com/job/dotty-master-validate-partest/906/console

where printing-pos failed, the compiler output only contains:

compiling /home/jenkins/workspace/dotty-master-validate-partest/tests/partest-generated/pos/printing/Disambiguation.scala /home/jenkins/workspace/dotty-master-validate-partest/tests/partest-generated/pos/printing/PlainPrinter.scala /home/jenkins/workspace/dotty-master-validate-partest/tests/partest-generated/pos/printing/Printer.scala /home/jenkins/workspace/dotty-master-validate-partest/tests/partest-generated/pos/printing/Printers.scala /home/jenkins/workspace/dotty-master-validate-partest/tests/partest-generated/pos/printing/RefinedPrinter.scala /home/jenkins/workspace/dotty-master-validate-partest/tests/partest-generated/pos/printing/Showable.scala /home/jenkins/workspace/dotty-master-validate-partest/tests/partest-generated/pos/printing/Texts.scala /home/jenkins/workspace/dotty-master-validate-partest/tests/partest-generated/pos/printing/package.scala
options: -Xprint-types -Ytest-pickler -Ystop-after:pickler -pagewidth 160 -Yno-deep-subtypes -Yno-double-bindings -d ./tests/partest-generated/pos/printing-pos.obj -Ycheck:tailrec,resolveSuper,mixin,restoreScopes,labelDef

Not informative.

@DarkDimius
Copy link
Contributor

To get the archive of workspace:
https://scala-ci.typesafe.com/job/dotty-master-validate-partest/906/ than click the Build Artifacts link.
It should have a *.clog file for every failed test:

dark@reco ~/Downloads/archive 2 $ find . -iname "*.clog"
./tests/partest-generated/pos/printing-pos.clog

@smarter
Copy link
Member

smarter commented Jan 14, 2016

@smarter Maybe you are right. I fixed checkNonCyclic and your example compiles OK (i.e. with errors) now.

So should we revert the original fix since it's not actually needed?

trait Bar[T] {
type Elem = T
}
trait Foo2[T <: Bar2[T]#Elem] // error: illegal cyclic reference
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Did you intend to have the same test twice, with just the names changed? (Foo -> Foo2, Bar -> Bar2)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, because 1 expected error also succeeds if the file is not found.

@odersky
Copy link
Contributor Author

odersky commented Jan 14, 2016

@smarter I think the checkNonCyclic fix is worth doing anyway.

@smarter
Copy link
Member

smarter commented Jan 14, 2016

@smarter I think the checkNonCyclic fix is worth doing anyway.

You mean the containsRefinedThis fix, right? Anyway, LGTM once the tests pass.

@smarter
Copy link
Member

smarter commented Jan 14, 2016

Ok. I was able to get to the archives of workspace
But the log does no say much

@DarkDimius : looking at https://github.com/lampepfl/dotty/blob/master/test/dotty/partest/DPDirectCompiler.scala#L29 I see that it's trying to redirect the output by using a custom Context, but using a custom Context is currently broken, so I don' t think that can work: https://github.com/lampepfl/dotty/blob/da661c8a509efaa1c0ff926b0907c32cd37708a5/src/dotty/tools/dotc/Driver.scala#L37-L39
It also won't include the output of calls to println, etc. It might be simpler to just always redirect stdout and stderr using https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#setOut-java.io.PrintStream- and https://docs.oracle.com/javase/8/docs/api/java/lang/System.html#setErr-java.io.PrintStream-

@smarter
Copy link
Member

smarter commented Jan 14, 2016

Anyway, LGTM once the tests pass

Actually, there's a missing change: remove the comment at https://github.com/lampepfl/dotty/pull/1026/files#diff-2fe35c59082b97d7128120593f9ec2e7R172 about #Apply which is no longer accurate.

@odersky
Copy link
Contributor Author

odersky commented Jan 14, 2016

/rebuild

containsRefinedThis inspects symbols and infos of named types in order
to avoid needless traversals. As i974 shows, this can lead to infinite
recursions. The fix is not to force a NamedType denotation, assume the
worst and traverse the prefix if a NamedType is not yet populated
with a denotation.

Fixes scala#974 and makes MutableSortedSetFactory in stdlib compile.
Previous jenkins run did not run out of memory but ran very slowly, indicating
trashing. Trying with half the heap size.
Leaving some last stop to print something even for fatal exceptions.
Need to also look info refined types.
Need to handle case where we hit a NoCompleter again.
I observed in a local partest a file with was a java.io.Path, not an SFile.
They should be treated like SFiles. Not clear why this came up. The file
in question (partest-generated/pos/Patterns_v1.scala) looked just like
all the others that were read as SFiles.
(reverted from commit a7bc089)
@odersky
Copy link
Contributor Author

odersky commented Jan 15, 2016

Superseded by #1028

@odersky odersky closed this Jan 15, 2016
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Higher-kinded F-bounded types are not recognized
3 participants