Shortest Code to Legitimately Slack Off

TikZ (pdfTeX 3.14159265-2.6-1.40.17), 85 79 74 24 22 21 bytes

A bunch of bytes saved thanks to wchargin

One byte saved thanks to Chris H

\input tikz
\tikz\pic

I actually encountered this one by accident when I was working on homework. I spent quite a while waiting for it to compile before I realized what was happening.

This has two parts:

\input tikz

This loads the TikZ package

and:

\tikz\pic

This starts a \tikz environment and a draw command.

What is going on

The pdflatex compiler has trouble with \tikz\pic, and enters interactive mode causing it to stall indefinitely.

C, 18 bytes

#include __FILE__

Compilers will usually give up after recursing about 200 times.

Does DOM construction count as a compilation step? If so, then x.htm:

<iframe src=x.htm>

Java, 102 95 89 88 78 bytes

class A<T>{}class B<T>extends A<A<?super B<B<T>>>>{A<?super B<A>>a=new B<>();}

This terminates with a StackOverflowError which happens because the generic resolution system can't decide a root against which to resolve the other generics.

Credits where due.

What happens here?

1. A<T> is just there to have a 1-letter parent. It's generic. I could have used List, but the imports and repetition of 4 letters are too long.
2. B<T> declares a basic generic.
3. B extends A is required to have a hierarchy between B and A.
4. extends A<A> creates a self reference on A<T>.
5. A<? super B> triggers the lookup for generics on A<T>
6. B<B<T>> creates a self-reference on B<T>.
7. A<...> a=new B<>() forces the usage of the generics, instead of simply the definition of those, forcing the resolution when compiling B, and not afterwards.
8. A<?super B creates a non-self-reference, so we have both a reference to one type and to another in the generics of A.
9. B<A> creates a non-self-reference, so we have both a reference to one type and to another in the generics of B.

Now, the type A has generics type A and B, but which is to be chosen? Forget about self, let's try to resolve B. Ping.

Okay, B has generics type A and B, but which is to be chosen? Forget about self, let's try to resolve A. Pong.

This kind of recursion can't really be avoided because there are legitimate cases like A<B<A<B<A<B<Object>>>>>>: for example a JSON object: List<Map<String,Map<String,List<Map<String,List<String>>>>>>.

Compilation result

$ javac NoCompile.java


The system is out of resources.
Consult the following stack trace for details.
java.lang.StackOverflowError
        at com.sun.tools.javac.code.Types$UnaryVisitor.visit(Types.java:3260)
        at com.sun.tools.javac.code.Types$23.visitClassType(Types.java:2587)
        at com.sun.tools.javac.code.Types$23.visitClassType(Types.java:2579)
        at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:554)
        at com.sun.tools.javac.code.Types$UnaryVisitor.visit(Types.java:3260)
        at com.sun.tools.javac.code.Types$23.visitClassType(Types.java:2592)
        at com.sun.tools.javac.code.Types$23.visitClassType(Types.java:2579)
        at com.sun.tools.javac.code.Type$ClassType.accept(Type.java:554)

On my system, the stack trace stops after showing 1024 lines, which are actually the 4 same lines repeated 256 times, thus proving an infinite recursion. I'll spare you that whole trace.

Savings

1. 102 → 95 bytes: replaced interface+implements with class+extends.
2. 95 → 89 bytes: replaced Long with A (twice).
3. 89 → 88 bytes: used diamond operator (new B<A>() → new B<>()) .
4. 88 → 78 bytes: moved the variable declaration to a class member, thanks to VoteToClose.