155
\$\begingroup\$

I'm a developer, and I don't feel like doing my work. I know from XKCD that the best excuse for slacking off is that your code's compiling. Because of this, I think I need some code that will compile forever! And because I'm lazy and don't want to have to type much, this has to be done with the shortest code possible.

So, your task is to write a program that is syntactically valid, but will cause the compiler to enter an infinite loop.

Specifications

  • You must use a language that has a compiler, obviously.
  • Specify the implementation used in each solution.
  • This is , so the shortest valid solution (in bytes) wins.
  • The compiler can terminate from running out of memory or stack space.
Improve this question
\$\endgroup\$
14
  • 1
    \$\begingroup\$ @obarakon I disagree. Code from the other challenge cannot be ported to this challenge with any ease. The challenges while the both involve infinite looping are fundamentally different. \$\endgroup\$
    – Wheat Wizard ♦
    Commented Feb 16, 2017 at 1:22
  • 1
    \$\begingroup\$ @obarakon Not a dupe of this question either, as it's not code-golf. \$\endgroup\$
    – Esolanging Fruit
    Commented Feb 16, 2017 at 1:24
  • 2
    \$\begingroup\$ Related \$\endgroup\$
    – Wheat Wizard ♦
    Commented Feb 16, 2017 at 1:25
  • 1
    \$\begingroup\$ I'm not sure it fits this challenge (and even if it does it would score terribly), but for those interested here's how I would do it in Java : define an annotation processor(ideone snippet) which you'll use when invoking javac with its -processor option. It makes the compilation of any class hang forever. \$\endgroup\$
    – Aaron
    Commented Feb 16, 2017 at 9:59
  • 6
    \$\begingroup\$ For the answers that result in crashing the compiler: For the purpose of slacking, I would think you still want it to take as long as you can to crash. \$\endgroup\$
    – GuitarPicker
    Commented Feb 16, 2017 at 17:43

30 Answers 30

Reset to default
58
\$\begingroup\$

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.

Improve this answer
\$\endgroup\$
12
  • \$\begingroup\$ (1/2) I can't reproduce this. I get "Runaway argument? \draw l\end {document} ! File ended while scanning use of \tikz@next." pdflatex 3.1415926-2.5-1.40.14 (TeX Live 2013/Debian). tikz 2010/10/13 v2.10. This is standard apt install texlive-full on Ubuntu 14.04. \$\endgroup\$
    – wchargin
    Commented Feb 16, 2017 at 4:28
  • 1
    \$\begingroup\$ @wchargin I am using the same version of pdfTeX 3.14159265-2.6-1.40.17 (TeX Live 2016) and it does indeed loop indefinitely. Thanks for the tips. \$\endgroup\$
    – Wheat Wizard ♦
    Commented Feb 16, 2017 at 4:55
  • 1
    \$\begingroup\$ You can save a byte by using \pic instead of \draw` -- exactly the same behaviour (tested using tikz 1.142) \$\endgroup\$
    – Chris H
    Commented Feb 16, 2017 at 14:23
  • 3
    \$\begingroup\$ I can't believe I'm actually advocating not using TikZ, but surely the use of it is overkill here. What's wrong with the old \def\a{\a}\a (12 bytes)? Or, as this is code golf and ~ is active by default, \def~{~}~ (9 bytes)? \$\endgroup\$
    – Andrew Stacey
    Commented Feb 16, 2017 at 18:42
  • 3
    \$\begingroup\$ @LoopSpace Nothing is wrong with them I just didn't know the existed. If you would like to make your own answer then feel free. \$\endgroup\$
    – Wheat Wizard ♦
    Commented Feb 16, 2017 at 18:44
44
\$\begingroup\$

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.
Improve this answer
\$\endgroup\$
4
  • 2
    \$\begingroup\$ What am I looking at \$\endgroup\$
    – Addison Crump
    Commented Feb 20, 2017 at 14:26
  • \$\begingroup\$ You can shorten this to 78 bytes with: class A<T>{}class B<T>extends A<A<?super B<B<T>>>>{A<?super B<A>>b=new B<>();} \$\endgroup\$
    – Addison Crump
    Commented Feb 20, 2017 at 14:44
  • 1
    \$\begingroup\$ @VoteToClose You're looking at a prime example of undecidability in Java's generics. Each generic is supposed to be resolved against a common root to which is then a validated against. The thing here is that the generic of B contains a undecidable reference to the generic of A which in turn contains an undecidable reference to the generic of B. When the resolver can't decide, it checks included references, but here both generics refer to each other in an undecidable way (mostly thanks to self references and the super keyword. So the resolver actually ping-pongs between the two generics. \$\endgroup\$
    – Olivier Grégoire
    Commented Feb 21, 2017 at 2:14
  • \$\begingroup\$ I was thinking about creating a compile-time problem with cyclical annotations: public @interface X {@X(x=X.class)Class<? extends X> x();}... But I quickly realized why that wouldn't work lol. \$\endgroup\$
    – Magic Octopus Urn
    Commented May 16, 2017 at 18:35
42
\$\begingroup\$

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>
Improve this answer
\$\endgroup\$
8
  • 14
    \$\begingroup\$ I remember that recursive framesets used to crash IE4 so hard that it sometimes took down important OS components with it. So the HTML there probably counts. \$\endgroup\$
    – user62131
    Commented Feb 16, 2017 at 15:26
  • 11
    \$\begingroup\$ @ais523, that's because, in the IE4 days, Internet Explorer was an "important OS component". \$\endgroup\$
    – Mark
    Commented Feb 16, 2017 at 19:07
  • 2
    \$\begingroup\$ A bit of tweaking and it is valid PHP: <?include __FILE__;. \$\endgroup\$
    – Ismael Miguel
    Commented Feb 16, 2017 at 20:39
  • 6
    \$\begingroup\$ Can't post this answer because my rep isn't high enough, but two alternatives are: #include "/dev/zero" and #include "/dev/stdin" -- be careful running the first one!! \$\endgroup\$
    – rrauenza
    Commented Feb 17, 2017 at 18:31
  • 2
    \$\begingroup\$ When I tried it gcc's memory usage began quickly growing without bound, the system became unresponsive, and my watchdog eventually kicked in and rebooted. It was fairly amusing :) \$\endgroup\$
    – rrauenza
    Commented Feb 20, 2017 at 2:10
36
\$\begingroup\$

GNU Makefile, 8 7 bytes

One byte saved thanks to KonradRudolph

Saved as Makefile and invoked by make:

x:;make

This will produce an infinite build recursion on the first target found "x".

Needless to say that you don't really want to run this fork bomb on your production server. :-)

make
make[1]: Entering directory `/path/to/my/dir'
make
make[2]: Entering directory `/path/to/my/dir'
make
make[3]: Entering directory `/path/to/my/dir'
make
make[4]: Entering directory `/path/to/my/dir'
make
make[5]: Entering directory `/path/to/my/dir'
make
make[6]: Entering directory `/path/to/my/dir'
make
make[7]: Entering directory `/path/to/my/dir'
make
...

Alternate version, 5 bytes

Suggested by KonradRudolph:

x:;$_

$_ is a reference to the last argument of the previous command. More specifically, it is resolved here as the absolute path to the command being executed -- which is make itself.

This should work fine in a genuine Bash environment, but not on Windows+MinGW.

Improve this answer
\$\endgroup\$
3
  • 2
    \$\begingroup\$ Hmm, I don't think make does really compile the Makefile (it just interprets it). \$\endgroup\$
    – zeppelin
    Commented Feb 16, 2017 at 8:44
  • 3
    \$\begingroup\$ @zeppelin You're right, this is probably a borderline answer. That said, submissions that involved macro recursion at the preprocessor level will never start to compile any actual code either. \$\endgroup\$
    – Arnauld
    Commented Feb 16, 2017 at 8:52
  • 14
    \$\begingroup\$ It fits the intended goal: having an infinite build process. +1! \$\endgroup\$
    – YSC
    Commented Feb 16, 2017 at 9:32
25
\$\begingroup\$

Perl, 15 13 bytes

BEGIN{{redo}}

Try it online!

Now with 2 bytes saved: @Zaid reminded me of a terser way to do a loop in Perl.

This is pretty simple: it just installs a parser hook with an infinite loop in, making the code take infinitely long to parse. (Perl's nice in that it allows you to run arbitrary code in the middle of the parse; the parser hooks are specified in Perl itself, and frequently used to do things like import libraries or change the parsing rules for an identifier you want to treat like a keyword.) The Try it online! link above gives the -c option (to compile the code to verify the syntax for correctness, but not run it), to prove that the infinite loop happens at compile time.

In case you're wondering about "compile time" in a scripting language: Perl actually compiles to bytecode and then runs the bytecode, but this is a detail that's rarely relevant when programming it. The -MO= command line option family can be used to do things with the bytecode other than running it (although not with this program, as the infinite loop happens before the bytecode can be generated).

Improve this answer
\$\endgroup\$
2
  • 1
    \$\begingroup\$ a:goto a looks nice too (same bytecount sadly). \$\endgroup\$
    – Dada
    Commented Feb 16, 2017 at 8:14
  • 3
    \$\begingroup\$ BEGIN{{redo}} will save you a few bytes \$\endgroup\$
    – Zaid
    Commented Feb 16, 2017 at 11:38
23
\$\begingroup\$

C++, 60 58

template<class T>class a{a<T*>operator->();};a<int>i=i->b;

This recursivly creates instances of class a with different template parameters. GCC 7.0 stops after 900 recursion levels with tons of errors about operator-> being private but for example ICC 17 and Microsoft (R) C/C++ Optimizing Compiler 19 time out on godbolt.

Problem with that is that probably all compilers will run out of memory at some point in time so even without recursion limits this will stop. The same probably applies to the Clojure answer, too.

Edit: 2 bytes saved by bolov - Thanks

Improve this answer
\$\endgroup\$
6
  • 1
    \$\begingroup\$ shorter: a<int>i=i->b; \$\endgroup\$
    – bolov
    Commented Feb 16, 2017 at 9:45
  • 1
    \$\begingroup\$ @Pockets like I stated in my answer that's because the operator-> is defaulted private within a class. Within a struct it's public and therefore i->b may access it. \$\endgroup\$
    – Christoph
    Commented Feb 20, 2017 at 6:32
  • 1
    \$\begingroup\$ gcc 4.4.7 seems to hang indefinitely here. Waiting for infinity or for it to show output, whichever comes first. Will update \$\endgroup\$
    – osuka_
    Commented May 17, 2017 at 6:21
  • 1
    \$\begingroup\$ @osuka_ is it still running? \$\endgroup\$
    – Christoph
    Commented Feb 13, 2018 at 7:07
  • 1
    \$\begingroup\$ @Christoph nope, it crashed with a SIGSEGV after I left it running for a couple days. Forgot to update, though - thanks for the reminder! \$\endgroup\$
    – osuka_
    Commented Feb 13, 2018 at 7:18
21
\$\begingroup\$

C++, 37 30 29 bytes

int f(auto p){f(&p);},a=f(0);

It uses the future auto function parameter. It was proposed into C++17, but I don't think it made it. gcc however supports it as an extension.

Basically

void foo(auto p);

is equivalent to

template <class T>
void foo(T p);

The code tries to instantiate f recursively with different template arguments. gcc fails with

fatal error: template instantiation depth exceeds maximum of 900 (use -ftemplate-depth= to increase the maximum)

With -ftemplate-depth=10000 I got it to spit "Killed - processing time exceeded" on godbolt.

Check it on godbolt

1 byte saved by Quentin. Thank you.

Improve this answer
\$\endgroup\$
2
  • 1
    \$\begingroup\$ One byte can be saved by using int as the return type :) \$\endgroup\$
    – Quentin
    Commented Feb 16, 2017 at 15:46
  • \$\begingroup\$ Indeed, auto function parameters didn't make it into C++17; and also int f() { ... }, a; isn't a legal declaration last time I checked. (You can't mix function declarations with variable declarations like that.) What you've got here is an extremely GCC-specific dialect of C++. Not that there's anything wrong with that in this context. :) \$\endgroup\$
    – Quuxplusone
    Commented Feb 20, 2017 at 9:30
19
\$\begingroup\$

Japt, 2 bytes

`ÿ

You can test this online here, but I wouldn't recommend it as it will freeze your browser.

Explanation

Japt uses the shoco library for compressing strings. A backtick tells the compiler to decompress everything until the next backtick or the end of the file. Each byte does the following:

  • 00-7F are left intact.
  • 80-BF each transform into a common lowercase two-letter pair (at, oo, th, etc.).
  • C0-DF each consume the next byte and transform into a common four-letter string.
  • E0-EF each consume the next three bytes and transform into a "common" eight-letter string (starting at Whererer and going downhill from there).
  • F0-F7 break the decompressor, though it still returns everything up to the breaking byte.
  • F8-FF cause the decompressor to enter into an infinite loop. I'm not sure why this is, as I'm not very familiar with the inner workings of the shoco library (and the JavaScript code is completely unreadable), but it's quite handy in this case.

I don't believe there is any other way to mess with the Japt compiler, but you never know...

Improve this answer
\$\endgroup\$
3
  • 14
    \$\begingroup\$ What do you mean it's unreadable. Clearly you just aren't trying hard enough. \$\endgroup\$
    – fəˈnɛtɪk
    Commented Feb 16, 2017 at 20:02
  • \$\begingroup\$ I wish there was an emscripten decompiler... \$\endgroup\$
    – tbodt
    Commented Feb 16, 2017 at 20:50
  • \$\begingroup\$ @tbodt In this case an emscripten decompiler is not needed, since the C source code is available at github.com/Ed-von-Schleck/shoco/blob/master/shoco.c (as linked from the comment at the top of the js file) \$\endgroup\$
    – Hjulle
    Commented Sep 13 at 19:18
18
\$\begingroup\$

Common Lisp, 8 bytes

#.(loop)

The compiler will try to read a form and will encounter the sharpsign-dot reader macro, which evaluates code at read time and uses its result as the form to compile. Here, the code being executed is an infinite loop.

Improve this answer
\$\endgroup\$
0
18
\$\begingroup\$

TeX, 9 bytes

\def~{~}~

TeX works by expanding macros. Most of the time, TeX's macros (also called control sequences) are of the form \name but it is also possible to define certain characters as macros, these are called active characters. The character ~ is active by default in plain TeX and so can be used as a macro name without further declaration. The \def~{~} in the above defines ~ so that it expands to ~. That is, whenever TeX encounters ~ then it replaces it by ~ and then re-examines the replacement, meaning that it encounters a wholly new occurrence of ~ and replaces that by ~. This defines the infinite loop. All that is then needed is to start the loop and that's what the final ~ does.

Added in edit

To make this properly compiled, invoke as:

pdftex -ini "&pdftex \def~{~}~"

The -ini flag says that pdftex should compile a new format file. This is a precompiled set of definitions which can be loaded when TeX is later invoked to speed up processing a document (LaTeX2e is an example of this). I guess that the &pdftex adds a few bytes, taking the total to 17.

Improve this answer
\$\endgroup\$
3
  • \$\begingroup\$ Does this happen at compile time? The question requires the infinite loop to happen while compiling, not when running. \$\endgroup\$
    – user62131
    Commented Feb 16, 2017 at 19:21
  • \$\begingroup\$ @ais523 Hadn't fully thought about that bit. I was riffing off the TikZ answer. I've added an alternative that is definitely compiled, at the expense of a few more bytes. \$\endgroup\$
    – Andrew Stacey
    Commented Feb 16, 2017 at 19:41
  • 3
    \$\begingroup\$ @ais523: As always, "compiling" and "running" are two sides of the same coin. Personally, I think of TeX source code as "compiling" into PDF documents (which are then "executed" by viewing), in the same way that C++ source code is "compiled" into .exe files (which are then "executed" by running). But you could also think of the pdftex program as "interpreting" TeX input to produce a PDF as "output" — in the same way that the g++ program "interprets" C++ input to produce an .exe file as "output". ;) \$\endgroup\$
    – Quuxplusone
    Commented Feb 20, 2017 at 9:35
17
\$\begingroup\$

gradle, 10 9 bytes

for(;;){}

with the above code placed in a build.gradle file. Gradle uses groovy as its base language so we are really talking about groovy here, but as the question was about build time I figured gradle would be more appropriate.

Running any gradle build commands with the above code prints the pointy-haired-boss-compatible build status line: 

$ gradle tasks
> Configuring > 0/1 projects > root project

if you are aiming for a raise, add the debug -d flag for: 

$ gradle -d tasks
14:56:25.522 [INFO] [org.gradle.internal.nativeintegration.services.NativeServices] Initialized native services in: .gradle/native
14:56:25.757 [DEBUG] [org.gradle.launcher.daemon.client.DaemonClient] Executing build 84908c0d-f28d-4c57-be61-40eaf0025e16.1 in daemon client {pid=27884}
14:56:25.761 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Adding IP addresses for network interface tun0
14:56:25.762 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Is this a loopback interface? false
14:56:25.762 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Is this a multicast interface? false
14:56:25.764 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Adding remote address /x:x:x:x:x:x:%tun0
14:56:25.764 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Adding remote address /x.x.x.x
14:56:25.764 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Adding IP addresses for network interface eth1
14:56:25.764 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Is this a loopback interface? false
14:56:25.764 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Is this a multicast interface? true
14:56:25.764 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Adding remote address /x:x:x:x:x:x:%eth1
14:56:25.764 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Adding remote address /x.x.x.x
14:56:25.764 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Adding remote multicast interface eth1
14:56:25.764 [DEBUG] [org.gradle.internal.remote.internal.inet.InetAddresses] Adding IP addresses for network interface lo
<snip>
14:57:07.055 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
14:57:07.056 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
14:57:07.056 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired.
14:57:07.056 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
> Configuring > 0/1 projects > root project

which in addition to looking impressively complicated also updates with a new set of: 

15:07:57.054 [DEBUG] [org.gradle.launcher.daemon.server.Daemon] DaemonExpirationPeriodicCheck running
15:07:57.054 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
15:07:57.054 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired.
15:07:57.055 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.
15:07:57.055 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Waiting to acquire shared lock on daemon addresses registry.
15:07:57.055 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Lock acquired.
15:07:57.055 [DEBUG] [org.gradle.cache.internal.DefaultFileLockManager] Releasing lock on daemon addresses registry.

status lines every 10 seconds making it look like the build is busy doing important technical...stuff.

Improve this answer
\$\endgroup\$
15
\$\begingroup\$

Haskell, 25+17=42 bytes

a= $(let a='a':a in[|a|])

A simple Haskell metaprogram which defines an infinite value and attempts to compute that value at compile time.

Invoke with ghc -XTemplateHaskell <file.hs> (+17 for the parameter to the compiler)

Improve this answer
\$\endgroup\$
5
  • \$\begingroup\$ Does $(let a=a in a) not work (for 32 bytes)? \$\endgroup\$
    – Ry-
    Commented Feb 20, 2017 at 3:45
  • 1
    \$\begingroup\$ Nope! GHC is too smart. Any infinite loop of the form let a = a in a gets rewritten to an exception, which simply causes a compiler error as opposed to an infinite loop. (although perhaps this would work with a different Haskell compiler, but I don't have one on hand to try) \$\endgroup\$
    – user2407038
    Commented Feb 20, 2017 at 8:13
  • \$\begingroup\$ It works with runghc for me, so I’d say it’s valid. (Actually, it works with ghc, too. 8.0.1 here.) \$\endgroup\$
    – Ry-
    Commented Feb 20, 2017 at 8:29
  • \$\begingroup\$ Really? I'm on ghc 8.0.1 as well - for me it gives Exception when trying to run compile-time code: <<loop>>, both in the interpreter and when compiling... technically the code above dies with an exception as well, but a stack overflow, which is explicitly allowed by the spec - and if you had infinite memory, it would really loop forever. The <<loop>> exception fires far before my machine runs out of memory. \$\endgroup\$
    – user2407038
    Commented Feb 20, 2017 at 8:39
  • \$\begingroup\$ This is very interesting, a= $(let a=a in a) gives me an infinite loop in GHCi, version 8.8.4 \$\endgroup\$
    – yyny
    Commented Jan 12, 2021 at 21:27
9
\$\begingroup\$

SWI-Prolog, 34 bytes

term_expansion(_,_):-repeat,1=0.

Explanation

term_expansion/2 is something that gets called automatically by the compiler before actually compiling code to transform some terms in the source code into other terms.

Here, we introduce a new rule for term_expansion/2: repeat,1=0..

repeat/0 is a predicate which always succeeds, and provides an infinite number of choice points.

1=0 is trying to unify 1 with 0, which is always false. This will cause the compiler to backtrack to repeat (since it always provides a choice point) and try 1=0 again, etc.

Improve this answer
\$\endgroup\$
3
  • \$\begingroup\$ Doesn't work in GNU Prolog, so I'm assuming this is implementation-specific. You might want to put the name of a compiler in the heading. (I'm assuming SWI Prolog.) \$\endgroup\$
    – user62131
    Commented Feb 16, 2017 at 15:25
  • \$\begingroup\$ @ais523 Thanks, didn't check on other distribs, but since compiler stuff is usually pretty specific, I should have known better... \$\endgroup\$
    – Fatalize
    Commented Feb 16, 2017 at 15:28
  • \$\begingroup\$ @ais523 However according to this, you might be able to use expand_term instead (as it says term_expansion cannot be used like here in GNU Prolog). It doesn't work with expand_term on SWI though. \$\endgroup\$
    – Fatalize
    Commented Feb 16, 2017 at 15:30
9
\$\begingroup\$

GNU Make, 44

.PHONY:x
$(MAKEFILE_LIST):x;sleep 1;touch $@

I can't claim credit for this. It is derived from Robert Mecklenburg's book Managing Projects with GNU Make: The Power of GNU Make for Building Anything.

When make executes this makefile, it sees the makefile is out of date (because the .PHONY target is out of date, so it executes the touch command, which updates the timestamp of the makefile. Then make re-reads the file and discovers the makefile is out of date.... Well you get the idea.

I prefer this to the other Make answer because it does not use recursion. On my VM, the other Make answer continues forking processes and at somewhere around 7,000 deep, the VM grinds to an unresponsive halt. However, with this answer it is able to continue indefinitely without eating up system resources. You really will be able to slack off with this build. I've gone over 1,000,000 iterations with no apparent system degradation.

Note I had to add the sleep 1 so that the makefile timestamp is actually updated every time. You can change this to sleep 0.01 if you want it to burn through iterations a bit faster.

Improve this answer
\$\endgroup\$
7
\$\begingroup\$

GNU Forth, 15 bytes

Golfed

: : [do] [loop]

Re-defines (re-compiles) the word : and invokes an immediate infinite loop [do] [loop] inside the new definition (right at the compile time).

One category of words don't get compiled. These so-called immediate words get executed (performed now) regardless of whether the text interpreter is interpreting or compiling.

Try It Online !

Improve this answer
\$\endgroup\$
6
\$\begingroup\$

C, 31 bytes (16 + 15 for -mcmodel=medium)

main[-1llu]={1};

Inspired by Digital Trauma. Compile with the -mcmodel=medium flag.

Good luck compiling this, you'll need 1.8 yottabytes of RAM and disk space.

Improve this answer
\$\endgroup\$
1
  • 2
    \$\begingroup\$ I might be misunderstanding how this works, but does this actually loop forever? It seems like it'd just take an impossibly long amount of time/amount of resources to compile. \$\endgroup\$
    – rydwolf
    Commented Aug 18, 2021 at 16:03
5
\$\begingroup\$

Clojure, 21 bytes

(defmacro a[]`(a))(a)

Ties up the compiler by defining a macro that repeatedly emits calls to itself.

On my phone, this causes the REPL to hang and lag the device. On my laptop, this fails outright with a StackOverflow.

Unfortunately the StackOverflow happens instantly, but it's still valid according to the rules.

Improve this answer
\$\endgroup\$
0
5
\$\begingroup\$

Haskell (GHC, without Template Haskell or custom rewrite rules), 138

{-#LANGUAGE FlexibleContexts,UndecidableInstances#-}
data A x=A
class C y where y::y
instance C(A(A x))=>C(A x)where y=A
main|A<-y=pure()

Theoretically, this enters an infinite loop in much the same way the C++ approach does: the polymorphic method y is instantiated to ever more convoluted types. In practice, the default allotted stack size actually overflows quickly:

$ ghc-7.10 wtmpf-file14146.hs 
[1 of 1] Compiling Main             ( wtmpf-file14146.hs, wtmpf-file14146.o )

wtmpf-file14146.hs:5:9:
    Context reduction stack overflow; size = 101
    Use -fcontext-stack=N to increase stack size to N
      C (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A (A t0))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))))
    In a stmt of a pattern guard for
                   an equation for ‘main’:
      A <- y
    In an equation for ‘main’: main | A <- y = pure ()

Credits to Luke Palmer.

Improve this answer
\$\endgroup\$
5
\$\begingroup\$

MSBuild, 130 bytes

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
    <Target Name="X">
        <Exec Command="msbuild"/>
    </Target>
</Project>

Save this as a file with .proj extension, and run with msbuild from the command prompt. MSBuild will run its only target which simply spawns another msbuild process.

Improve this answer
\$\endgroup\$
3
  • \$\begingroup\$ Is the indentation required for this to work? What about the newlines? It's normally possible to golf out whitespace. \$\endgroup\$
    – user62131
    Commented Feb 16, 2017 at 15:28
  • \$\begingroup\$ No, it's just easier to read. The character count doesn't include whitespace. \$\endgroup\$
    – Danko Durbić
    Commented Feb 16, 2017 at 15:45
  • 1
    \$\begingroup\$ Ah right. In that case you should probably mention that in the body of the post. \$\endgroup\$
    – user62131
    Commented Feb 16, 2017 at 15:55
4
\$\begingroup\$

Mathematica 33 Bytes

Compile[{},Evaluate@While[True,]]

The code will attempt to symbolically evaluate the argument prior to compilation, and the argument itself is an infinite loop. The While function has a null second argument since it's not important.

Improve this answer
\$\endgroup\$
3
3
\$\begingroup\$

Rust, 18 bytes

include!(file!());

Classic self-include. Rustc is annoyingly sane though, and by default will bail out after 128 recursions, and it expands depth-first so exponential growth doesn't work either. The same applies to the C and C++ solutions though.

Improve this answer
\$\endgroup\$
2
\$\begingroup\$

Factor, 29 16

<< [ t ] loop >>

The part between << >> is executed at parse time.

As for what [ t ] loop does, I'll let you guess...

You can put that in the Listener as is, or add it to any vocabulary or script file with the corresponding boilerplate stuff.

Improve this answer
\$\endgroup\$
2
\$\begingroup\$

Haskell (ghc), 32 + 2 = 34 bytes

{-#RULES""main=main#-}
main=main

run with ghc -O <file>. Triggers a rewrite rule for the main function which rewrites to the same thing. The only unfortunate feature is that ghc is smart enough to detect this and stop after 100 iterations. I don't know of an easy way to disable this behavior.

Improve this answer
\$\endgroup\$
2
\$\begingroup\$

Civet --comptime, 13 bytes

comptime loop

When the --comptime flag is set, an expression or indented block preceded by the word comptime is evaluated at compile time. loop <statements> compiles to while (true) { <statements> }; since version 0.7.2, the number of statements may be zero.

Playground link. By default --comptime is not set for security reasons, and you need to check a box in the bottom right of the output to enable it. Do so at your own risk.

Improve this answer
\$\endgroup\$
1
\$\begingroup\$

Boo, 25 bytes

macro l:
 x=0 while 1>0
l

This defines a macro, which executes at compile time, which executes an infinite loop, and then invokes the macro.

Improve this answer
\$\endgroup\$
1
\$\begingroup\$

PHP, 19 bytes

<?include __FILE__;
Improve this answer
\$\endgroup\$
1
\$\begingroup\$

Nim, 25 bytes

static:
 while 0<1:echo 2

Try it online!

Compile with --maxLoopIterationsVM:10000000000000000. The compiler on TIO is old and doesn't support this flag.

Improve this answer
\$\endgroup\$
1
\$\begingroup\$

Julia 1.0, 16 bytes

@generated !x=!x

not a full program but a function, since Julia compiles functions the first time they are called

I'm pretty sure that's a compile-time infinite loop, since @code_llvm (which only compiles the function whithout executing it) also loops forever

Try it online!

Improve this answer
\$\endgroup\$
0
\$\begingroup\$

Scala 3, 47 bytes

type T[X]=X match{case 1=>T[X]}
val x:T[1]= ???

Try it in Scastie!

Terminates saying "Recursion limit exceeded."

Improve this answer
\$\endgroup\$
0
\$\begingroup\$

Typst, 18 bytes

#let f()=f()
#f()

Produces the following error:

$ typst c loop.typ
error: maximum function call depth exceeded
  ┌─ loop.typ:1:9
  │
1 │ #let f()=f()
  │          ^^^

help: error occurred in this call of function `f`
  ┌─ loop.typ:2:1
  │
2 │ #f()
  │  ^^^

Typst, 36 bytes

A solution that works without overflowing the stack.

#{let a=(1,);while a.len()>0{a+=a}}

Simpler solutions are detected as potentially infinite:

$ typst c loop.typ
error: condition is always true
  ┌─ loop.typ:1:7
  │
1 │ #while true{}
  │        ^^^^

$ typst c loop.typ
error: condition is always true
  ┌─ loop.typ:1:7
  │
1 │ #while 1 < 2{}
  │        ^^^^^

$ typst c loop.typ
error: loop seems to be infinite
  ┌─ loop.typ:2:1
  │
2 │ #while a>0{a+=1}}
  │  ^^^^^^^^^^^^^^^

$ typst c loop2.typ
error: loop seems to be infinite
  ┌─ loop2.typ:1:13
  │
1 │ #{let a=(1,);while a.len()>0{a.push(1)}}
  │              ^^^^^^^^^^^^^^^^^^^^^^^^^^
Improve this answer
\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.