<p dir="auto">The <code class="notranslate">type_overflow</code> lint does not catch integral literals larger than <code class="notranslate">i64::MAX</code>. I have to assume the problem is the overflow happens when generating the AST, and the lint operates on the AST, so it can't tell that it overflowed.</p>
<p dir="auto">Example:</p>
<div class="highlight highlight-source-rust notranslate position-relative overflow-auto" dir="auto" data-snippet-clipboard-copy-content="println!(&quot;{}&quot;, 9223372036854775808i64);
// prints -9223372036854775808
println!(&quot;{}&quot;, 18446744073709551615i64);
// prints -1"><pre class="notranslate"><span class="pl-en">println</span><span class="pl-en">!</span><span class="pl-kos">(</span><span class="pl-s">"{}"</span>, <span class="pl-c1">9223372036854775808i64</span><span class="pl-kos">)</span><span class="pl-kos">;</span>
<span class="pl-c">// prints -9223372036854775808</span>
<span class="pl-en">println</span><span class="pl-en">!</span><span class="pl-kos">(</span><span class="pl-s">"{}"</span>, <span class="pl-c1">18446744073709551615i64</span><span class="pl-kos">)</span><span class="pl-kos">;</span>
<span class="pl-c">// prints -1</span></pre></div>
<p dir="auto">It does manage to catch <code class="notranslate">18446744073709551616</code>, which is a parse error ("int literal is too large"). This is <code class="notranslate">u64::MAX + 1</code>, so the parser can definitively tell it's too large even though it doesn't know which integral type is being used.</p>
<p dir="auto">As per a FIXME in syntax::parse::lexer, check (maybe in the parser, definitely somewhere earlier than trans) that 32-bit and 64-bit floating-point literals are in the right range.</p>