| <!DOCTYPE html><html lang="en"><head><meta charset="utf-8"><meta name="viewport" content="width=device-width, initial-scale=1.0"><meta name="generator" content="rustdoc"><meta name="description" content="Diagnostics rendering and fixits."><title>ide_diagnostics - Rust</title><script>if(window.location.protocol!=="file:")document.head.insertAdjacentHTML("beforeend","SourceSerif4-Regular-6b053e98.ttf.woff2,FiraSans-Italic-81dc35de.woff2,FiraSans-Regular-0fe48ade.woff2,FiraSans-MediumItalic-ccf7e434.woff2,FiraSans-Medium-e1aa3f0a.woff2,SourceCodePro-Regular-8badfe75.ttf.woff2,SourceCodePro-Semibold-aa29a496.ttf.woff2".split(",").map(f=>`<link rel="preload" as="font" type="font/woff2" crossorigin href="../static.files/${f}">`).join(""))</script><link rel="stylesheet" href="../static.files/normalize-9960930a.css"><link rel="stylesheet" href="../static.files/rustdoc-84e720fa.css"><meta name="rustdoc-vars" data-root-path="../" data-static-root-path="../static.files/" data-current-crate="ide_diagnostics" data-themes="" data-resource-suffix="" data-rustdoc-version="1.89.0 (29483883e 2025-08-04)" data-channel="1.89.0" data-search-js="search-92309212.js" data-settings-js="settings-5514c975.js" ><script src="../static.files/storage-4e99c027.js"></script><script defer src="../crates.js"></script><script defer src="../static.files/main-fd3af306.js"></script><noscript><link rel="stylesheet" href="../static.files/noscript-32bb7600.css"></noscript><link rel="alternate icon" type="image/png" href="../static.files/favicon-32x32-6580c154.png"><link rel="icon" type="image/svg+xml" href="../static.files/favicon-044be391.svg"></head><body class="rustdoc mod crate"><!--[if lte IE 11]><div class="warning">This old browser is unsupported and will most likely display funky things.</div><![endif]--><nav class="mobile-topbar"><button class="sidebar-menu-toggle" title="show sidebar"></button></nav><nav class="sidebar"><div class="sidebar-crate"><h2><a href="../ide_diagnostics/index.html">ide_<wbr>diagnostics</a><span class="version">0.0.0</span></h2></div><div class="sidebar-elems"><ul class="block"><li><a id="all-types" href="all.html">All Items</a></li></ul><section id="rustdoc-toc"><h3><a href="#structs">Crate Items</a></h3><ul class="block"><li><a href="#structs" title="Structs">Structs</a></li><li><a href="#enums" title="Enums">Enums</a></li><li><a href="#functions" title="Functions">Functions</a></li></ul></section><div id="rustdoc-modnav"></div></div></nav><div class="sidebar-resizer" title="Drag to resize sidebar"></div><main><div class="width-limiter"><rustdoc-search></rustdoc-search><section id="main-content" class="content"><div class="main-heading"><h1>Crate <span>ide_diagnostics</span><button id="copy-path" title="Copy item path to clipboard">Copy item path</button></h1><rustdoc-toolbar></rustdoc-toolbar><span class="sub-heading"><a class="src" href="../src/ide_diagnostics/lib.rs.html#1-853">Source</a> </span></div><details class="toggle top-doc" open><summary class="hideme"><span>Expand description</span></summary><div class="docblock"><p>Diagnostics rendering and fixits.</p> |
| <p>Most of the diagnostics originate from the dark depth of the compiler, and |
| are originally expressed in term of IR. When we emit the diagnostic, we are |
| usually not in the position to decide how to best “render” it in terms of |
| user-authored source code. We are especially not in the position to offer |
| fixits, as the compiler completely lacks the infrastructure to edit the |
| source code.</p> |
| <p>Instead, we “bubble up” raw, structured diagnostics until the <code>hir</code> crate, |
| where we “cook” them so that each diagnostic is formulated in terms of <code>hir</code> |
| types. Well, at least that’s the aspiration, the “cooking” is somewhat |
| ad-hoc at the moment. Anyways, we get a bunch of ide-friendly diagnostic |
| structs from hir, and we want to render them to unified serializable |
| representation (span, level, message) here. If we can, we also provide |
| fixits. By the way, that’s why we want to keep diagnostics structured |
| internally – so that we have all the info to make fixes.</p> |
| <p>We have one “handler” module per diagnostic code. Such a module contains |
| rendering, optional fixes and tests. It’s OK if some low-level compiler |
| functionality ends up being tested via a diagnostic.</p> |
| <p>There are also a couple of ad-hoc diagnostics implemented directly here, we |
| don’t yet have a great pattern for how to do them properly.</p> |
| </div></details><h2 id="structs" class="section-header">Structs<a href="#structs" class="anchor">§</a></h2><dl class="item-table"><dt><a class="struct" href="struct.Diagnostic.html" title="struct ide_diagnostics::Diagnostic">Diagnostic</a></dt><dt><a class="struct" href="struct.DiagnosticsConfig.html" title="struct ide_diagnostics::DiagnosticsConfig">Diagnostics<wbr>Config</a></dt></dl><h2 id="enums" class="section-header">Enums<a href="#enums" class="anchor">§</a></h2><dl class="item-table"><dt><a class="enum" href="enum.DiagnosticCode.html" title="enum ide_diagnostics::DiagnosticCode">Diagnostic<wbr>Code</a></dt></dl><h2 id="functions" class="section-header">Functions<a href="#functions" class="anchor">§</a></h2><dl class="item-table"><dt><a class="fn" href="fn.full_diagnostics.html" title="fn ide_diagnostics::full_diagnostics">full_<wbr>diagnostics</a></dt><dd>Request both syntax and semantic diagnostics for the given [<code>FileId</code>].</dd><dt><a class="fn" href="fn.semantic_diagnostics.html" title="fn ide_diagnostics::semantic_diagnostics">semantic_<wbr>diagnostics</a></dt><dd>Request semantic diagnostics for the given [<code>FileId</code>]. The produced diagnostics may point to other files |
| due to macros.</dd><dt><a class="fn" href="fn.syntax_diagnostics.html" title="fn ide_diagnostics::syntax_diagnostics">syntax_<wbr>diagnostics</a></dt><dd>Request parser level diagnostics for the given [<code>FileId</code>].</dd></dl></section></div></main></body></html> |
